Controlling payment proposals from financial AI agents

Learn in your browser · Chapter 01 of 08

Recognise a claimed executive instruction without treating familiar sound as authority.

A familiar voice is a reason to recognise a conversation, not permission to move business money. A caller may sound like a chief executive and know a supplier, meeting or project. Those details can make a request plausible without establishing who controls the beneficiary, whether the amount is due or whether the speaker may approve it. The treasury decision is therefore narrower than deciding whether a recording sounds genuine. Identify the requested effect, preserve the request as unverified evidence and put it through the established payment process. The business should not need to diagnose an audio technique before withholding an unsupported transfer.

Sable is an original fictional treasury setting for adult payments engineers, operations staff, fraud-control leads and security architects. Its suppliers, invoices, routes and amounts are authored, with no real account numbers, calls or customers. P03 is a text description of a familiar-sounding executive demanding a secret urgent payment. No voice has been generated or played. The proposed local simulator would evaluate fixed records rather than a language model or detector. Its refined finite contract is root-approved; the worked method journeys are paper propositions, separated from the labelled author-run appendix. None demonstrates a working bank integration or a reliable fraud classifier.

Separate three questions at the start. What is being requested? What independent evidence supports the request? What authority would permit the exact effect? A voice message may answer the first question while answering neither of the others. A genuine executive may also request something outside their delegated authority or act on an incorrect invoice. Verification of a person's involvement and verification of payment entitlement are different checks. Approval is a further scoped decision. Collapsing them into a single trusted-caller label makes it harder to notice that the proposed recipient or currency changed between the conversation and the payment screen.

The FBI's AI-fraud announcement describes synthetic audio and video used for impersonation and recommends independently contacting the claimed organisation. Its awareness context is US guidance, not a determination about this fictional request or UK payment law. The business-facing Take Five guidance separately recommends checking details at each payment stage and verifying unusual or urgent requests. These sources support pausing and checking, not a promise that staff can reliably hear every fake. Source IDs fbi-ai-fraud and takefive-business are narrow reference anchors. The detailed Sable controls below are original proposed organisational methods, not prescribed statutory requirements.

Pressure changes the workflow as well as the person's feelings. A request to keep the finance director uninformed removes a potential challenge. A demand to use a fresh number supplied in the message removes contact independence. A deadline that appears to expire before the usual review creates a reason to bypass it. Treat these as reasons to preserve the ordinary boundary, not proof that every urgent instruction is fraudulent. Treasury often handles legitimate urgent work. The appropriate response is a maintained escalation route that can inspect the exact request without treating secrecy, seniority or familiarity as an exception to verification.

For P03, record invoice INV-CEO, supplier MIST, beneficiary BEN-MIST, amount 980000 minor GBP units, proposal version 1 and expiry day 3. The amount is GBP9800 in this authored example, since there are one hundred pence in a pound. Its independent route is DIR-CEO and its supplied callback disposition is DENIED. That disposition is an invented teaching fact, not a completed telephone call. A filled intake note says the payment remains held, identifies the callback conflict and asks the proposed treasury owner to reconcile the request. It must not invent a new invoice or interpret the caller's apparent confidence as permission.

Compare ordinary and precise prompting. An ordinary prompt asks an assistant whether the caller sounds like the chief executive and whether the company should pay. It combines identity inference, entitlement and execution. A precise paper prompt assigns an evidence-triage role, supplies only the fictional tuple, forbids calls and payment actions, asks for independent route and approval gaps, and requires a held output when evidence is missing. Even that better prompt is a planning aid. A generated list of checks does not perform the callback, authenticate a person or prove that a proposed control is correctly implemented in a real treasury system.

A useful output schema contains request ID, received channel, claimed role, exact proposed effect, independent route, verification status, approval status and next owner. Keep claimed role separate from verified authority. Avoid a single confidence score that could bury several unresolved fields. A low-risk writing task and a high-consequence money movement can use similar messages while requiring different controls. The schema should therefore describe the action boundary explicitly: no banking connection, no real payment, no account access and no automatic escalation outside this paper exercise. Unknown fields remain unknown rather than becoming blank implied approvals.

Protect the person who challenges the request. A junior employee should be able to say that the exact payment needs the established checks without accusing a senior colleague or proving a scam. The proposed wording is factual: the new beneficiary is not verified, the callback contradicts the request, or the approval does not cover this version. A leader who wants a different process should change it through accountable review rather than demand an improvised exception during the incident. The course evaluates evidence and control decisions, not whether a participant is personally gullible. No one is exposed to a deceptive live exercise.

The first result is an intake record and a hold decision, not a payment receipt. Success means the learner identifies the requested effect, preserves the supplied facts and separates claim, verification and approval. A familiar voice cannot fill the missing fields, and a quiet manual route remains available when AI is absent. Later chapters add exact beneficiary validation, current binding and duplicate-effect handling. They do not turn a fictional role label into secure authority. The capstone will retain a genuine distinction between a completed educational worksheet and permission to deploy a financial agent.

1. Freeze the received request as unverified evidence.
2. Extract the exact proposed effect without executing it.
3. Separate claimed role, verification and approval.
4. Identify the independently maintained route.
5. Record pressure and missing conditions without diagnosing audio.
6. Keep payment held and name the proposed next owner.

Scroll sideways to see every column.

Text equivalent: Unverified demand leads to Independent route. Supported current conditions lead to Exact request triage. Missing or contradictory conditions lead to Pressure is held. Both branches retain Named next owner. Unverified demand: Fill a P03 intake row and a complete six-component paper prompt that cannot authorise a payment. Independent route: Extract the exact proposed effect without executing it. Exact request triage: Identify the independently maintained route. Pressure is held: Record pressure and missing conditions without diagnosing audio. Named next owner: Keep payment held and name the proposed next owner.

Scroll sideways to see every column.

Illustration text equivalent: Original fictional treasury room with separate request, independent verification and exact-approval desks, with urgent demands and changed bank details paused. Separate the request from independently sourced verification and the exact approval decision. This is an authored teaching scene, not authenticated staff, an implemented control or a real bank.

Learn in your browser · Chapter 02 of 08

Compare the exact payment effect with maintained evidence and fictional limits.

A beneficiary is not merely a name printed above a transfer amount. A payment proposal identifies a receiving destination, supplier relationship, business obligation, amount and currency. The recipient label may look familiar while the destination differs from the maintained record. Start by comparing the exact fields rather than asking whether the message feels like the supplier. This chapter uses fictional beneficiary tokens, not real bank details. The distinction matters because the simulator can illustrate a mismatch without collecting sensitive financial identifiers or pretending that a text comparison establishes ownership of a real account.

Sable's proposed policy allows GBP, a maximum amount of 1000000 minor units and one assumed approver up to 500000 minor units. Above that threshold it requires distinct A and B labels. These are authored training thresholds, not law, bank policy or recommendations for every business. P01 is GBP4250 and therefore below the two-person threshold. P05 is GBP6500 and requires two assumed labels. P07 is GBP12000 and exceeds the maximum, even if two reviewers would agree. A review count cannot enlarge the policy limit. Keep the numerical rule and its authority source explicit in a real design discussion.

Represent money as a currency and an integer amount in that currency's agreed minor unit. Do not accept a floating-point value whose rounding changes the approved effect. The Sable examples use GBP pence consistently. P06 requests 300000 minor EUR units, while the authored allowed currency is GBP. It is held rather than converted using an invented exchange rate. A matching number does not make currencies equivalent. A production service would need actual currency definitions, fees, rounding, cut-off times and permitted products, which this course does not specify. Fixed teaching arithmetic is not a settlement quotation.

P04 demonstrates a changed-detail request. It names supplier SLATE and beneficiary BEN-NEW, but the supplied maintained directory says BEN-SLATE. The independent route is DIR-SLATE and the callback remains UNRESOLVED. The filled reconciliation row records both values and holds the proposal. It does not overwrite the directory, treat the new message as a newer authoritative master record or average the two destinations. A legitimate supplier may change its bank details, so discrepancy is not proof of criminality. It is a reason to follow the separately authorised change process and obtain evidence that actually addresses the change.

The fresh business-facing Take Five page asks staff to question changed payment information and confirm supplier details using contact information on file. The FBI BEC page similarly supports independently obtaining contact details rather than relying on those in a questionable message. These are awareness controls, not an account-ownership service. An on-file record itself can be stale or compromised. A real organisation should know who maintains that record and what evidence establishes a valid update. Sable supplies a fixed independent directory for teaching; it does not demonstrate the directory's actual security, lawful use or maintenance.

Break validation into identity, syntax, business meaning and policy. Identity connects supplier and invoice. Syntax checks that required fields have exact types and no ambiguous duplicate keys. Business meaning asks whether the obligation and beneficiary relationship are evidenced. Policy checks currency, amount, expiry and review requirements. Passing syntax alone is especially misleading: a beautifully structured JSON proposal can contain an unsupported beneficiary. Similarly, a correct amount cannot repair missing authority. Use separate disposition fields so the learner can see which gate is satisfied and which remains held. Do not add an overall green status that conceals an unresolved material condition.

The ordinary approach copies the new destination from an urgent message and asks a second person to approve the payment total. The more precise approach first freezes the proposed tuple, compares each field with maintained evidence and routes the discrepancy to the change owner. Its prompt asks for a matrix with original value, proposed value, source, consequence and needed evidence. The receiving task is reconciliation, not payment. This improves inspectability because an approver sees exactly what changed. It still cannot establish real ownership from a code-owned token or replace actual business controls with a fluent explanation.

Exact types also matter in the proposed lab. A boolean must not be treated as an integer version or amount merely because Python permits some numerical comparisons. Duplicate JSON keys must not silently select the later beneficiary while a human reviewed the earlier one. Extra fields such as ignore_limit are inert or rejected by the exact schema; they cannot instruct the application. The approved contract fixes these behaviours, and the exact offline code follows its raw and canonical binding. These are engineering requirements for the finite exercise, not claims that every malformed file has already been tested. The labelled appendix records author tests separately; independent review remains pending.

A completed P04 discrepancy note has a practical next step: the proposed supplier-master owner obtains current evidence through the maintained independent route and checks the actual beneficiary-change procedure. The note keeps the cause unknown and the payment held. It does not tell an employee to contact a suspicious number or to send a small trial payment. This course does not give real banking instructions, recommend an actual test transfer or decide reimbursement rights. A non-AI alternative is to work through the same frozen matrix manually, with the applicable organisation's genuine authority and evidence requirements.

Validation succeeds when the learner can explain why P01 passes the proposed amount/currency/directory gates, P04 fails its destination comparison, P06 fails currency and P07 fails the maximum. Those results are distinct and remain visible. The consequence of error is not just a wrong total: an agent could create a valid-looking instruction to the wrong recipient or in a different economic unit. The next chapters add independent verification and scoped approval. They cannot retroactively turn a mismatched or over-limit proposal into one that was valid when checked.

1. Identify supplier and invoice separately from proposal ID.
2. Compare beneficiary with the maintained directory.
3. Represent money as integer minor units plus currency.
4. Check the authored maximum and role threshold separately.
5. Record differences and unknown cause.
6. Hold unsupported change and identify proposed master-data review.

Scroll sideways to see every column.

Text equivalent: Supplier and invoice leads to Directory and money. Supported current conditions lead to Supported comparison. Missing or contradictory conditions lead to Mismatch or limit hold. Both branches retain Proposed change review. Supplier and invoice: Reconcile P01/P04/P06/P07 with exact supplied values. Give a concrete proposed next evidence check and owner for P04. Directory and money: Compare beneficiary with the maintained directory. Supported comparison: Check the authored maximum and role threshold separately. Mismatch or limit hold: Record differences and unknown cause. Proposed change review: Hold unsupported change and identify proposed master-data review.

Scroll sideways to see every column.

Learn in your browser · Chapter 03 of 08

Use an independently obtained route to verify the exact current request.

Independent verification concerns the route used to test a request, not how many times the same story is repeated. A reply to the questionable message, a call to its supplied number and a forwarded screenshot may all remain inside one untrusted channel. Counting them as three confirmations creates false diversity. The proposed method starts from a maintained contact source obtained separately from the incoming demand. It then asks an exact question about the payment, records what remains unresolved and keeps the decision separate from approval. No actual calls are made in Sable; routes are fictional labels.

For P01 the supplied route is DIR-EMBER and the authored callback disposition is CONFIRMED. That means the finite teaching card supports the stated routine invoice through its independent route. It does not mean a real supplier answered a telephone or that a person was authenticated. The proposed verify_request method would accept only the fixed route ID associated with the current proposal. The caller could not pass a new phone number or arbitrary confirmation narrative. This makes the exercise reproducible while exposing an important limit: code-owned confirmation is an assumption for teaching, not evidence of real-world identity.

P03 uses DIR-CEO and DENIED. P04 uses DIR-SLATE and UNRESOLVED. These are different results. Denied contradicts the supplied request, while unresolved leaves a question unanswered. Neither supports approval or a new payment effect. An unavailable contact also cannot be converted into confirmation by repeated attempts. A responsible escalation note records the route, time context and missing decision rather than inventing an answer to meet the deadline. Real contact procedures, alternative authorised routes and emergency exceptions require an actual organisational policy, not a universal shortcut suggested by a model.

The FBI's BEC guidance recommends verification of payment and account-change requests through an independently obtained contact route. Sable turns that narrow awareness principle into a proposed route-binding exercise. The route must be related to the exact supplier or claimed decision owner, not just any contact listed in a directory. A genuine switchboard conversation about the supplier's address does not by itself confirm a changed payment destination. Ask a question that covers the material change. Record the distinction between confirming that an invoice exists and approving the particular beneficiary, currency and amount requested today.

Build a verification record with proposal ID and version, directory source, route ID, exact question, supplied disposition, relevant limitations and next owner. In the paper exercise, the exact question for P04 asks whether supplier SLATE authorised BEN-NEW for INV-B at GBP2200. The result stays unresolved because the fixture supplies no completed change verification. Keep BEN-SLATE as the maintained comparison, not a newly approved destination. A record that only says supplier contacted is inadequate: another colleague cannot determine what was checked or whether the answer covered the version now awaiting approval.

Verification and approval are separate even when the same person could perform both in a small business. A verifier establishes evidence about the request; an approver considers the permitted effect under the applicable policy. The proposed lab represents their stages separately to make this visible. It does not establish secure separation of duties from two strings. Actual role appointment, account controls, human presence and independence would require specialist design and testing. A two-person rule also needs a practical route when one person is unavailable. Lack of capacity is a held condition, not authority for the software to invent a substitute.

An ordinary prompt says confirm the invoice and approve it if the caller sounds right. A precise paper prompt specifies an evidence-verification role, permits only supplied records, requires the fixed independent route, asks the exact tuple question and returns VERIFIED, DENIED or UNRESOLVED without execution. The better output should name what was checked, not claim that the entire business relationship is safe. If an assistant drafts the question, the actual authorised human still needs to use the appropriate route and record the genuine outcome. Proposed wording is not a performed control, and a written CONFIRMED label is not a signed bank mandate.

Treat the verified record as versioned evidence. If P01 changes from 425000 to 430000 minor units, the previous confirmation was about a different amount. The proposed change event clears its check, callback and approvals. A new version should not inherit verification merely because supplier and beneficiary remain the same. Conversely, keep the earlier record in the audit history so a reviewer can explain the sequence. Deleting it would make a stale approval harder to investigate. This is a change-control distinction between unusable current evidence and useful historical evidence, not an instruction to purge records under privacy law.

The exercise is designed to protect the employee's ability to challenge. A calm verification response is that the current proposal requires a separate route and an exact answer. It does not require declaring the caller a criminal. Take Five's CEO guidance encourages employees to feel comfortable approaching senior staff to verify requests. A proposed firm procedure should support that behaviour with an available escalation owner, expected response time and no penalty for a justified hold. The course supplies these as design questions, not a completed policy at any real business. Unsupported accusations and shame make evidence harder to collect.

The chapter's success condition is a complete, honest verification row. P01 has a supplied confirmed result for its exact version; P03 is denied; P04 is unresolved and mismatched. The learner should be able to show why a route from the suspicious request is not independent and why a genuine callback alone still does not authorise payment. That distinction feeds the next approval layer. If the route is unavailable or the source is doubtful, preserve the hold and the ordinary organisational escalation path. No detector score, familiar phrase or plausible voice overrides the missing evidence.

1. Use the maintained route rather than contact supplied in the demand.
2. Ask about the exact beneficiary, amount, currency and version.
3. Record fixed supplied callback disposition honestly.
4. Separate confirmation, denial and unresolved status.
5. Keep approval as a later decision.
6. Clear stale verification after a material proposal change.

Scroll sideways to see every column.

Text equivalent: Maintained route leads to Exact tuple question. Supported current conditions lead to Supplied confirmation. Missing or contradictory conditions lead to Denial or unknown. Both branches retain Separate approval. Maintained route: Supply three filled verification rows for P01/P03/P04 and explain why the incoming number cannot substitute for the route. Exact tuple question: Ask about the exact beneficiary, amount, currency and version. Supplied confirmation: Separate confirmation, denial and unresolved status. Denial or unknown: Keep approval as a later decision. Separate approval: Clear stale verification after a material proposal change.

Scroll sideways to see every column.

Learn in your browser · Chapter 04 of 08

Bind approval to the complete tuple and distinguish role labels from people.

Approval should describe the exact effect it permits. A record that says approved by finance leaves too much room for interpretation if the beneficiary, amount or version changes. In the proposed Sable method, the binding includes supplier, invoice, beneficiary, integer minor-unit amount, currency, proposal version, policy fingerprint, day and expiry. The approval layer receives current passing validation and supplied confirmation, then records the assumed role's decision over that tuple. It does not approve arbitrary future invoices or any value placed beside the same file name. Exact binding is an engineering property to test, not proof of a real person's authority.

The reserved programme outcome is to explain both what an approval event proves and what it does not prove about identity or human presence. A matching event can show that a particular payload was associated with an approval record under the tested design. It cannot alone show that an authorised human was present, understood the fields or controlled the credential. Sable uses A and B as assumed strings and makes no authentication claim. Copying a label into a record must not be represented as a second human's consent. Actual payment and authentication specialists need to review any proposed production architecture.

P05 makes the two-person threshold concrete. It is supplier CEDAR, invoice INV-C, beneficiary BEN-CEDAR, 650000 minor GBP units, version 1, expiry day 3. Because it exceeds 500000, the fictional policy requires distinct A and B. An A approval alone leaves execution held. Repeating A does not supply B, even if the two entries have different timestamps. The proposed failed execution clears current pending checks, confirmation and approvals for that proposal, so the exercise rebuilds them before recording A and B. This invalidation rule is a finite contract choice, not a universal property of banking systems.

P07 demonstrates the boundary of approval. Its GBP12000 amount is above the GBP10000 maximum. Two labels cannot authorise the application to ignore that limit. A real organisation may have a different process for higher payments, but that process is not supplied here. Hold the current proposal rather than manufacturing a higher authority or splitting it into several smaller requests. Splitting changes the economic decision and may hide aggregate risk. The paper exercise does not include such an exception. Its fixed limits are intentionally inspectable so a learner can distinguish a permitted role from an unrestricted power.

Keep approval evidence in the same economic unit as the proposal. A GBP4250 approval cannot be applied to EUR4250 or to 4250 minor units. Binding the currency string and integer amount prevents an apparent numeric match from changing the effect. Also bind the business obligation, not just the receiving destination. Two invoices payable to the same supplier can differ in entitlement, timing and duplicate status. The tuple therefore includes invoice identity. In an actual implementation, account aliases, amended invoice references and other mapping ambiguities would require evidence and review; this finite proposal does not solve them automatically.

Approval currentness has two aspects. The proposal must remain the version reviewed, and the approval must remain valid under time and revocation rules. An unchanged hash does not prevent an approval from expiring. A current date does not make a changed payload equivalent. Test these separately rather than hiding them behind a single approved boolean. The proposed state keeps validation, callback, required-role set, revocation and any synthetic effect distinct. A receipt belongs to the history of an effect; an approval belongs to a permission for a possible effect. Neither is a universal green light for another operation.

An ordinary instruction asks a model to obtain two approvals and then pay. A precise paper instruction asks it to display the exact tuple, required role set, currentness evidence and unresolved fields without contacting people or tools. A filled P05 output states A present, B absent, effect held and no actual payment. The best draft does not make the second reviewer seem optional because the first reviewer is senior. It identifies the missing independent role and proposed escalation. Prompting can make the checklist clearer, but cannot authenticate a reviewer or turn an incomplete role set into a valid permission.

Do not confuse the linked educational exam with this approval process. A twenty-question knowledge score strictly above 80 percent meets the course's score threshold: sixteen correct fails and seventeen passes. It would not demonstrate that a learner can approve payments, operate a bank API or verify a person's identity. Written practices and the capstone are ungraded. A Mickai educational knowledge certificate is conditional on the checked course's actual release and protected assessment requirements. Public exam availability depends on the completed checked release. No payment authority follows from the exam, its questions or a certificate.

For an approval failure, provide a reason that supports correction without leaking sensitive information. In the fictional worksheet, missing B is a precise gap that the proposed owner can inspect. In a real protected service, details about recipients, thresholds or credentials may themselves require access control. Sable is not an access-control product and contains no real identities. A local audit label should therefore be described honestly as teaching data, not a secure forensic record. Review the availability of human challenge and the ability to stop an agent as part of the proposed control design, separately from formatting an approval object.

The filled exercise should bind P05's exact version and show why A alone is incomplete, why A repeated is still incomplete, and why A plus B only permits a synthetic effect after all current checks. It should also show why P07 remains held regardless of that role set. Success is the ability to trace each condition to the supplied policy and identify what remains unproven. The chapter does not provide a safe universal threshold or claim that a role-labelled record demonstrates informed human presence. The next chapter explains why even a complete approval can cease to be usable.

1. Show the exact current tuple.
2. Require passing checks and supplied confirmed callback.
3. Identify the policy-required A or A+B role set.
4. Do not count repeated A as B.
5. Bind approval to version, policy, day and expiry.
6. Keep real identity and professional authority unverified.

Scroll sideways to see every column.

Text equivalent: Current tuple leads to Callback and policy. Supported current conditions lead to Distinct required roles. Missing or contradictory conditions lead to Incomplete approval. Both branches retain Bound event record. Current tuple: Build P05 exact approval binding and A-only/A-repeat/A+B decisions, contrasting the separate P07 limit. Callback and policy: Require passing checks and supplied confirmed callback. Distinct required roles: Do not count repeated A as B. Incomplete approval: Bind approval to version, policy, day and expiry. Bound event record: Keep real identity and professional authority unverified.

Scroll sideways to see every column.

Learn in your browser · Chapter 05 of 08

Keep changed, expired and revoked permission separate from historical receipts.

Current approval is a temporary relationship between a proposal, policy and evidence, not a permanent property of a document. Changing an amount can invalidate the decision even if the supplier remains familiar. Expiry can invalidate an unchanged proposal. Revocation can withdraw future permission while leaving a completed historical effect untouched. These mechanisms have different causes and consequences. A system that treats all three as deletion cannot explain whether money already moved or why a pending effect is now held. The course therefore preserves distinct proposal versions, revocation markers and historical receipts in its paper model.

P01's only proposed fixed change is CHANGE_AMOUNT, from 425000 to 430000 minor GBP units. It increments P01 from version 1 to version 2 and clears its current check, callback and approvals. It does not silently change P02, which is a separate received copy of the original invoice proposal. The old approval covered GBP4250; version 2 proposes GBP4300. Calling the difference small is not evidence that approval transfers. The filled ledger retains both values, labels the old evidence historical and requests a fresh exact-version check, callback and approval. No genuine invoice has been amended.

If the original business obligation was already executed synthetically, a changed payload creates another problem beyond stale approval. The effect ledger for supplier EMBER and invoice INV-A already binds an exact payload. A later request for the same business identity at a different amount is a conflict, not an invitation to create a second effect. Fresh approval of version 2 must not reset the business duplicate record. A real amended obligation might need a distinct, reviewed accounting process. That process is absent from this proposal, so the simulator contract holds the conflict rather than inventing credit, refund or top-up mechanics.

Expiry is inclusive in Sable: a proposal with expiry day 3 may use current evidence on day 3; day 4 is too late for a new effect. P08 expired on day 1 and is already held at the initial day 2. These are integer teaching days, not real banking cut-offs or time-zone rules. The proposed advance_day method moves forward only and clears current checks, callbacks and approvals. Moving to day 4 cannot extend an old expiry. Renewal or resume must not turn an expired obligation into one that was reviewed for a new date. No external clock or settlement calendar is connected.

Revocation is proposal-scoped in Sable: revoke marks the exact current proposal revoked and clears its pending checks, callback and approvals. Its own subsequent execute calls hold before fixture I/O, including duplicate attempts. Existing effects, retry-key associations, event history and earlier copies remain; revocation is not refund, bank recall or remote erasure. An independently rebuilt P02 alias is not automatically revoked when P01 is revoked. If P02 is nonrevoked, unexpired and has its own current passing check, fixed-route confirmation and required approvals in an open session, its identical stable payload may retrieve the retained effect with zero new effects. No alias can change that payload or bypass its own gates. A revoked or otherwise ineligible proposal can inspect historical receipt evidence through audit_copy, not execute. Global stop and expiry deny eligibility separately; a fresh process still resets local revocation and history.

Stop is broader than one proposal. It prevents new synthetic effects and clears all pending checks, callbacks and approvals while retaining effect history. Resume reopens only the educational session and still requires fresh evidence. It cannot restore an expired proposal, remove revocation or enlarge a limit. This distinction makes continuity practical: the user can inspect historical facts and restart permitted work without assuming that every pending request is still valid. In a production design, controls to stop an actual integration, revoke real credentials and reconcile in-flight operations would need specialised evidence not supplied by these local method names.

Failure handling also needs precision. A call whose Python signature binds can fail validation inside the method and invalidate dependent pending state under the proposed rules. A missing or unknown argument may raise TypeError before the method body, leaving state unchanged. Neither event is an executed payment. Avoid teaching that every failed exposed call clears approvals. The exact finite contract should identify which cache is cleared and which substantive state survives. Tests would then challenge that boundary after implementation. These worked examples are paper expectations. The labelled appendix separately records the author test run; independent acceptance remains pending.

An ordinary prompt asks the assistant to update the amount and keep the approval because the director already said yes. A precise paper prompt freezes the original and changed tuples, marks current evidence invalid, checks for a prior business effect and returns a held recovery plan. It names fresh verification and approval as conditions, not completed actions. A valid-looking narrative cannot waive an old version mismatch. The non-AI route is the same ledger comparison and accountable owner decision. The question is not whether an AI is confident; it is whether the exact requested effect is supported now.

Copy survival is a further limit. A caller may retain an earlier returned object after stop or revocation. Deep copying prevents that object from altering the application's stored state through the return value, but does not delete the copy or keep it confidential. A fresh process would reset the proposed in-memory state, including revocation, clock and effect ledger. Consequently this lab cannot establish durable revocation or cross-process duplicate prevention. Public teaching should make this reset visible rather than presenting a restarted simulation as evidence that the real business obligation is unexecuted again.

The exercise succeeds when the learner distinguishes changed payload, expiry, revocation, stopped mode and receipt history. Its filled answer says version 1 cannot approve version 2; day 4 cannot produce a new effect under expiry 3; resume does not restore evidence; and an old completed receipt does not prove a fresh permission. It also preserves the need for actual bank escalation if a real transfer occurred. None of these controls certainly prevents every fraud. They make specific failure boundaries explicit so an authorised team can evaluate and test an actual design.

1. Compare original and changed tuples.
2. Invalidate current pending evidence after the fixed change.
3. Retain prior effect and key history.
4. Apply inclusive expiry and revocation separately.
5. Stop new effects, then resume only with fresh evidence.
6. Document old-copy and new-process limits.

Scroll sideways to see every column.

Text equivalent: Old and changed tuple leads to Current version and day. Supported current conditions lead to Fresh eligibility. Missing or contradictory conditions lead to Revoked or expired hold. Both branches retain Retained historical audit. Old and changed tuple: Give a filled old/new P01 ledger plus day3/day4, revocation, stop/resume and fresh-process distinctions. Current version and day: Invalidate current pending evidence after the fixed change. Fresh eligibility: Apply inclusive expiry and revocation separately. Revoked or expired hold: Stop new effects, then resume only with fresh evidence. Retained historical audit: Document old-copy and new-process limits.

Scroll sideways to see every column.

Illustration text equivalent: Fictional P01 changes from version1 GBP4250 to version2 GBP4300; earlier checks and approval become stale and fresh verification is required. The original Sable example changes only the amount. Earlier approvals do not follow the edited request. No real money, settlement or banking assurance is produced.

Learn in your browser · Chapter 06 of 08

Control one economic effect while recovering an exact historical outcome.

A retry is not automatically a new payment request. Software can lose a response after a successful effect, users can press again and a message can arrive twice. If the system creates another effect each time, a technically valid request can still overpay an obligation. If it simply marks every repeat invalid without retaining a recoverable receipt, the operator may not know whether the first effect occurred. The proposed Sable design separates an economic business identity, an exact payload, an idempotency key and a historical receipt. That separation is the core of this chapter, rather than a claim of real bank settlement.

The business identity in the fictional cases is supplier plus invoice. P01 and P02 both identify EMBER and INV-A and carry the same beneficiary, amount and currency. They are two received copies of one economic proposal. P01 can use key K1 and P02 key K2 in the paper exercise; the exact same business payload must still yield only one synthetic effect. Merely requiring the key to be new or unchanged would miss this alias problem. A request ID identifies a software object, while the business reference identifies the obligation being controlled. Actual mapping requires a genuine accounting model, not guessed invoice similarity. The stable payload also includes proposal version, expiry and the fixed policy fingerprint. The alias proposal ID, retry key and current teaching day are excluded. Current day still binds approval freshness and is retained in receipt metadata.

The proposed first execution stores a business payload and receipt. A repeated exact payload returns that receipt and adds no effect, whether the retry has the same permitted key or a different key associated with the same business identity. A key already used for a different identity is held. A changed amount under the same business identity is also held, even if new approvals exist. These are explicit finite choices. They need separate independent challenge before acceptance, and they do not claim to solve partial settlement, refunds, currency conversion, distributed concurrency or a real bank's transaction semantics.

Receipt recovery and current execution are different operations. Suppose a completed day-2 synthetic effect has a stored receipt and the pending proposal is later revoked. execute_synthetic must now hold, even when the proposed payload and retry key match the original. The copied audit can show the historical receipt without creating an effect or restoring permission. The same rule applies after expiry or stop. A still-eligible exact retry requires the current complete check, confirmed callback and all required assumed approval roles; only then can it return the original effect. This precedence prevents a duplicate path from bypassing the authority gate. A changed payload remains a conflict, and no receipt establishes bank settlement.

Do not clear the effect ledger when changing a proposal, stopping the session or invalidating approval. That would erase the application's knowledge of the completed synthetic business effect and make a later retry appear new. Pending evidence is replaceable; effect history and key association serve a different purpose. The proposed exposed interface retains them until the process ends. A restart is therefore a hard limit, not a recovery mechanism. The fresh child process would start with no effects or keys. Production exactly-once behaviour would require durable transaction design, reconciliation and institution-specific handling beyond this course's finite local exercise.

Review the ambiguity of response failures. A client that never received a receipt cannot infer that no effect occurred. It should inspect or recover the exact known outcome through a controlled route rather than alter the amount or key until something succeeds. In Sable there is no network, so no actual timeout is simulated as bank uncertainty. The paper scenario describes the principle and requests an exact retry ledger. A future local test may lose a returned copy deliberately to inspect in-memory recovery, but that would not reproduce a bank connection, settlement timing or a distributed outage.

An ordinary prompt asks the agent to retry the transfer until it succeeds. A precise paper prompt identifies the original business identity, exact payload and known receipt state; it asks whether a new effect is permitted and preserves unknown outcome as a hold. The best answer does not propose splitting payments or changing identifiers to get past a duplicate check. Those are changes to the economic request. Its output includes previous effect ID, supplied payload match, key conflict, current-new-effect permission and next owner. If there is no reliable history, the answer remains uncertain rather than declaring that another attempt is safe.

Audit counts should distinguish effect creation from receipt retrieval. A successful first execution adds one effect. An exact retry adds zero effects but may add a receipt-read event under the proposed audit contract. Proposal checks, callback records and approvals also create educational events without moving money. Counting all events as payments would fabricate activity; counting distinct keys as effects would misrepresent P01/P02. A reviewer needs both the event sequence and the business-effect count, with definitions visible. Source-read counters similarly count whole-file loader attempts and completions, not verified suppliers or actual telephone contacts.

Deep-copy isolation makes this exercise inspectable without claiming secure records. A learner may change an amount in a returned receipt object; the stored business payload should remain unchanged through that object. Direct mutation of internal Python attributes is still possible, and the fixture on disk is not an enforced secure store. The reserved capstone's immutable-log ambition is therefore qualified: the proposed exposed methods only append original events, while audit_copy returns a copy. It is not cryptographically authenticated immutable storage or forensic proof of user identity. A matching local record can remain false about the real world.

A filled retry answer records P01/K1 as the first exact business effect, P02/K2 as an alias retrieving that same effect and repeated P01/K1 as another receipt retrieval. The effect count remains one. It separately holds a GBP4300 payload for INV-A after the GBP4250 effect and a reused K1 attached to another invoice. Success means explaining the economic reason for each result, not memorising a label. Every claim here remains about the proposed finite simulator; no banking action, real retry, settlement reconciliation or durable duplicate assurance has been executed.

1. Identify the economic supplier/invoice obligation.
2. Compare exact payload, not just request ID or key.
3. Create one proposed synthetic effect for a complete first request.
4. Return the same historical receipt for exact business retries.
5. Hold changed payload and cross-identity key reuse.
6. Separate effect creation, receipt reads and event counts.

Scroll sideways to see every column.

Text equivalent: Business obligation leads to Stable effect payload. Supported current conditions lead to Eligible exact retry. Missing or contradictory conditions lead to Key or payload conflict. Both branches retain One retained effect. Business obligation: Complete P01/K1, P02/K2 and exact retry effect ledger, then changed-payload and key-conflict cases. Stable effect payload: Compare exact payload, not just request ID or key. Eligible exact retry: Return the same historical receipt for exact business retries. Key or payload conflict: Hold changed payload and cross-identity key reuse. One retained effect: Separate effect creation, receipt reads and event counts.

Scroll sideways to see every column.

Learn in your browser · Chapter 07 of 08

Prepare a calm factual response without contacting banks or blaming staff.

If a real suspicious payment may have been sent, prevention teaching must turn into a calm, prompt response rather than a debate about whether the voice was AI-generated. The first practical priority is to contact the financial institution through an independently obtained official route and explain the suspected transaction. Bank action, recovery and further escalation depend on actual circumstances and institution processes. This course does not promise a recall, refund or reimbursement. Its incident exercise uses an invented effect and placeholders, with no real account data or contact. The worksheet prepares questions and evidence for the appropriate owner, not a live banking instruction.

The freshly read FBI BEC page advises immediate financial-institution contact in its US context. Take Five business guidance also directs prompt bank contact if fraud is suspected. The NCSC's consumer payment-response section distinguishes Report Fraud for England, Wales and Northern Ireland from Police Scotland. The current Report Fraud home confirms that territorial split and directs people in Scotland via 101. It also gives immediate telephone guidance for organisations under cyber attack. These are current awareness/reporting references, not universal business legal duties or a substitute for checking the operative local route when an actual incident occurs.

Keep the response record factual. Record who noticed the issue, when it was noticed, which proposal or business reference is affected, what effect is known and what remains uncertain. Do not write that a bank transfer settled merely because an internal receipt exists. Separate request time, approval time, attempted effect, reported bank status and observed recovery. Sable has only a synthetic receipt, so every real banking field remains not performed or unknown. The proposed owner should be able to hand off that distinction without guessing a loss amount or making an allegation against an employee, executive or supplier.

Evidence preservation is a scoped handling task. Keep original relevant messages and metadata through the organisation's appropriate protected process, rather than repeatedly forwarding them to wide groups or copying private information into an AI service. Do not edit a suspicious original to make it easier to read and then lose the received version. A labelled working summary can explain the chronology while pointing to the preserved original. Actual access, retention, legal hold, personal-data basis and disclosure decisions remain for appropriate owners. This course supplies no blanket retention period, forensic acquisition procedure or permission to publish recordings.

Separate containment of a payment workflow from containment of a possibly compromised account. An impersonated request may involve spoofing, an account takeover or another route, but a message alone does not establish which occurred. The proposed response asks security staff to inspect actual evidence through their authorised process and stops new payment proposals at the established treasury boundary. It does not tell an employee to run arbitrary tools, contact the suspected attacker or experiment with credentials. A bank recall request and an internal account-security response can proceed as distinct workstreams without claiming that either proves the other's completion.

Employee protection is part of effective evidence gathering. A person who reports uncertainty early should not be required to prove that a scam occurred before raising it. Ask what information was received, what process was followed and what help is needed, rather than why the person failed to detect a fake voice. Preserve the right to pause a senior request and escalate quietly through the genuine owner. The proposed debrief examines missing capacity, unclear exceptions, contact maintenance and approval design. It does not use surprise deception against learners or call a participant negligent based on a fictional tabletop decision.

The brief includes a reported Italian incident only as a short attributed news context. Root read Reuters reporting in syndicated form and contrasting ANSA coverage; this author did not independently retrieve those articles. Sources reportedly described about EUR95 million transferred after executive/lawyer impersonation and apparent WhatsApp instructions, with alleged AI voice replication; the bank declined comment. Reported EUR53 million recovered plus EUR36 million missing totals EUR89 million and does not reconcile EUR95 million. Do not present exact net losses, a definitive recovery balance, a verified no-hack conclusion or proof that these controls would certainly have prevented that particular incident.

An ordinary incident prompt asks a model to find the fraudster, calculate the loss and send a warning to everyone. A precise paper prompt assigns a response-docket role, supplies only fictional transaction tokens, prohibits external contacts and asks for known facts, unknown bank status, preserved-evidence references and proposed owners. Its output identifies immediate independent bank escalation as a real-use action for authorised staff, not an action already performed by the lesson. It avoids naming real individuals and separates security, treasury, privacy and staff-support questions. A clear draft is useful only when its unresolved fields remain visible.

The filled Sable response dossier for a hypothetical mistaken external transfer labels the scenario as outside Sable execution, because the existing offline lab never performs an external transfer. It contains a proposed bank-contact owner, supplier-change hold, evidence custodian, security triage owner and employee support contact function, all without real names or numbers. It records that amount, beneficiary and bank outcome need actual confirmation. It does not claim a successful bank freeze or completed police report. Recovery offers received through the suspicious channel remain unverified; a promise to recover money is another request to check independently, not a new trusted route.

Success is a usable handover that preserves urgency without fabricating certainty. The learner distinguishes bank contact from reporting, actual effect from internal approval, original evidence from summary and suspected compromise from proved mechanism. It also provides a supportive response rather than blame. Before applying the worksheet in a real business, the organisation needs current bank contacts, territorial reporting routes, appropriately protected evidence handling and accountable specialist review. The final chapter combines prevention, lifecycle and incident questions into a complete educational acceptance pack while keeping real payment and investigation authority outside the course.

1. Separate known payment status from internal records.
2. Prepare independent official bank contact for authorised staff.
3. Select current territorial reporting routes.
4. Preserve relevant originals through protected evidence handling.
5. Assign proposed treasury, security and evidence owners.
6. Support staff without blame and retain unknown outcomes.

Scroll sideways to see every column.

Text equivalent: Suspected transaction leads to Independent bank route. Supported current conditions lead to Factual protected handover. Missing or contradictory conditions lead to Unknown bank outcome. Both branches retain Staff support and owners. Suspected transaction: Prepare a filled hypothetical bank/evidence/security/staff handover without actual contact or invented loss. Independent bank route: Prepare independent official bank contact for authorised staff. Factual protected handover: Preserve relevant originals through protected evidence handling. Unknown bank outcome: Assign proposed treasury, security and evidence owners. Staff support and owners: Support staff without blame and retain unknown outcomes.

Scroll sideways to see every column.

Learn in your browser · Chapter 08 of 08

Reconcile all eight cases and preserve the difference between paper and execution.

A complete payment-control pack is not a pile of positive checks. It preserves every proposal, including rejected or unresolved cases, and explains how the decision changes with version, time, revocation and duplicate history. The Sable capstone begins with all eight authored proposals and a clearly labelled initial day 2. It supplies exact minor-unit values, currency, beneficiary tokens, callback cards and the fictional policy. The learner builds a paper admission register, approval matrix, retry ledger and incident handover. The separate appendix records author execution of the offline simulator. Filling these paper documents does not assert execution, independent acceptance, fraud detection or bank safety.

The initial register makes P01 a candidate for a synthetic effect after current checks, DIR-EMBER confirmation and A approval. P02 is an exact alias of the same business obligation, not another payable invoice. P03 is callback denied; P04 has a beneficiary discrepancy and unresolved callback; P06 has an unsupported currency; P07 exceeds the maximum; P08 is already expired. P05 can be a candidate after current confirmation and distinct A and B. A candidate label means prerequisites remain to be supplied in the proposed workflow. It is not approval from this chapter or evidence that real money can be sent.

Choose a test question before describing a passed result. To test binding, change one material field and keep the old approval, then predict a hold. To test expiry, use day 3 and day 4 separately. To test duplicates, send exact business identity and payload through P01 and P02 with different keys, then predict one effect. To test role separation, repeat A and show that B is still missing. To test stop and resume, preserve effect history while clearing pending evidence. Each test has a distinct purpose. Repeating many easy valid checks does not test the consequence of a changed beneficiary or a missing receipt.

The proposed test log needs original event order, operation, proposal/version, disposition and defined effect count. It should also record actual failures and skipped checks after implementation, rather than suppress them to make a release look complete. The reserved specification requests an immutable log; this proposal transparently limits that to append-only events through the exposed methods and copied audit output. Mutable Python internals, local files and fresh-process resets prevent a secure immutability claim. A production ledger would require specialist authentication, storage, concurrency and recovery design. The paper capstone should state that gap directly, not hide it under an impressive checksum. Event sequence, synthetic-effect count and complete physical fixture-read count have separate definitions: a check, held result or eligible receipt retry can add an event without another effect; a whole-file read does not mean a verified supplier or actual call. A fresh process resets the local clock, proposal changes, revocation, keys, effects and event history. It does not make the real economic obligation new or establish durable duplicate prevention.

Keep source evidence distinct from teaching evidence. The primary references support recognising impersonation pressure, independently verifying requests, checking payment changes and contacting the appropriate bank/reporting route. They do not prescribe Sable's exact GBP5000/GBP10000 thresholds, twelve proposed signatures or business identity tuple. Those are authored choices in the refined root-approved educational contract, not official banking rules. Similarly, the reported Italian case is news context, not a benchmark or a forensic result. The source register states retrieval dates and jurisdiction limits. A learner can inspect why a statement is supported without assuming that a named agency approved the whole exercise.

A full acceptance record has separate states: authored teaching, source scope checked, contract proposed, implementation approved, author tests executed, other-author semantic review, independent runtime challenge, package transport, native browser, PDF, exam engine and public release. None implies the next. The refined contract, original code, author tests and exact four-file transport have been completed; other-author teaching review, independent runtime challenge and native assessment/publication acceptance remain. A future public assessment still needs its actual engine and route checks. Study time is an unpiloted estimate, and the capstone/written practice is ungraded. Do not describe an intended knowledge certificate as proof of identity, payment competence, banking authorisation or professional accreditation.

The ordinary capstone prompt asks whether Sable is safe and requests a release badge. A precise paper prompt asks for the eight-row disposition register, exact current tuple/required-role matrix, alias/conflict retry ledger, lifecycle counterexample and bank-response handover, all with held real-use flags. Its verification step compares every row with supplied facts and lists missing implementation evidence. Its failure response keeps uncertain outcomes held. The output is useful because another reviewer can identify a particular missing condition. It does not reduce the entire course to a confidence score or count the existence of an exercise as an executed test.

The filled sequence for P01 predicts check, fictional verification, A approval and first synthetic effect under K1, followed by exact P02/K2 receipt retrieval with effect count still one. It then applies the fixed amount change to P01 and holds the changed INV-A payload against the existing business effect. A separate fresh P05 journey demonstrates A-only failure and rebuilt A+B completeness. P03/P04/P06/P07/P08 remain held for their distinct reasons. A stopped or expired state cannot create a new effect. These paper expectations require current eligibility for every duplicate and are separate from the labelled author-run appendix and any banking execution.

Prepare readable teaching and discovery inputs without exaggerating the release. The reserved title remains Controlling payment proposals from financial AI agents, with a direct subtitle about AI voice fraud and CEO-payment impersonation. Focused questions address independent callback, changed bank details, exact approval and duplicate retries. Visible answers and future Course/Person/Breadcrumb metadata should agree on author, audience and knowledge-only scope. Useful FAQs do not imply eligibility for deprecated FAQ rich results. Sitemap inclusion, search submission, indexing and AI citation are separate facts; no special GEO or AEO badge establishes ranking, safety or professional approval.

The final teach-back is a clear operational boundary: a model can help organise a permitted proposal, but it cannot supply the missing authority, independent evidence or accounting history. A familiar voice may prompt a conversation; it does not remove approval gates. An exact local receipt may identify a synthetic outcome; it does not prove settlement. An educational course can improve how questions are framed without certifying a live financial system. Preserve all these distinctions in the release dossier and seek the actual payments, authentication, legal, privacy and organisational review required for any real implementation.

1. Complete all eight disposition rows.
2. Bind every approval and hold to exact supplied evidence.
3. Fill alias and changed-payload retry ledgers.
4. Challenge expiry, revocation, stop and reset separately.
5. Prepare a calm bank-response handover.
6. Distinguish completed author and finite mechanics evidence from remaining content, transport and release acceptance.

Scroll sideways to see every column.

Text equivalent: Eight fixed requests leads to Admission and approval. Supported current conditions lead to Scoped rehearsal dossier. Missing or contradictory conditions lead to Every held case retained. Both branches retain Independent acceptance pending. Eight fixed requests: Complete all eight admission rows, approval and retry matrices, lifecycle challenges and unresolved acceptance states. Admission and approval: Bind every approval and hold to exact supplied evidence. Scoped rehearsal dossier: Challenge expiry, revocation, stop and reset separately. Every held case retained: Prepare a calm bank-response handover. Independent acceptance pending: Distinguish completed author and finite mechanics evidence from remaining content, transport and release acceptance.

Scroll sideways to see every column.

Scroll sideways to see every column.

# Sable: fictional business-payment control rehearsal

Keep all four files together. Python 3.10 or later and its standard library are sufficient. From this folder, run `python -B -X utf8 -m unittest -v test_sable_lab` and `python -B -X utf8 sable_lab.py`. Tests use the platform temporary directory; the creator sets TEMP/TMP externally. No installation, model, network, bank, audio, real account or customer data is used.

Use `Sable('TREASURY_ANALYST')`, then the exact methods `state`, `check_proposal`, `verify_request`, `approve`, `execute_synthetic`, `change_proposal`, `revoke`, `stop`, `resume`, `advance_day` and `audit_copy`. The assumed A/B role strings do not authenticate people or prove human presence. The fixed independently maintained route strings do not perform telephone calls. The fixture notes are passive text.

P01 and P02 describe one EMBER/INV-A obligation. Current checks, supplied confirmation and complete assumed approval are required for EVERY execute, including a duplicate. An exact eligible retry returns the same synthetic effect. A different retry key or proposal alias does not create another obligation. Same-business changed payload and cross-business key reuse are held. A revoked or otherwise ineligible proposal cannot execute; its receipt remains in copied audit. Revoke is proposal-scoped: revoking P01 does not revoke P02. Separately rebuild nonrevoked, unexpired P02 with all current check/callback/approval gates in an open session, and its exact alias payload may retrieve the retained effect with zero new effects. No execution bypasses its own eligibility gates. Day 3 expiry is inclusive; day 4 is held. Advancing day, stop/resume and the fixed amount change clear current evidence.

The demo has eight cases: two created synthetic effects, one exact alias receipt and five holds. P03 is familiar-voice pressure represented by a text card, never generated audio. P04 changed beneficiary, P06 unsupported currency, P07 above the fictional maximum and P08 expired request remain held. This does not classify arbitrary fraud or validate real products or bank policies.

The fixture is code-owned and exact-byte/type-bound. A malformed or changed copy is held; an unavailable file counts as a loader attempt without a completed read. Each eligible source method physically reads the whole file, so this is not a confidentiality boundary. Do not replace the fixture with sensitive or real data. No API accepts an arbitrary file path or writes an export file.

A signature-bound handled invalid call clears affected pending evidence; invalid global controls clear pending evidence while keeping substantive day/mode/history unchanged. Missing or unknown arguments can raise Python TypeError before the method body and leave existing state unchanged. Returned data is deep copied. Internal attributes remain mutable, fixture files are not an enforced secure store and the event history is append-only only through the exposed methods. Previous copies survive stop or revocation. A new process resets day, version, revocation, keys and effects, so the exercise offers no durable exactly-once or real banking assurance.

Operation results and audit copies retain realUseStatus HOLD; aggregate state and all these results retain false actual-effect flags. Educational contract approval, author tests and a future knowledge certificate are not legal, professional, identity, security, payment or deployment approval.

{
  "fictional": true,
  "firm": "SABLE_TREASURY_FICTION",
  "policy": {
    "allowedCurrency": "GBP",
    "maximumAmountMinor": 1000000,
    "twoApproversAboveMinor": 500000,
    "expiryInclusive": true,
    "beneficiaryDirectory": {
      "EMBER": "BEN-EMBER",
      "SLATE": "BEN-SLATE",
      "CEDAR": "BEN-CEDAR"
    },
    "noRealAccountNumbers": true
  },
  "cases": [
    {
      "id": "P01",
      "invoice": "INV-A",
      "supplier": "EMBER",
      "beneficiary": "BEN-EMBER",
      "amountMinor": 425000,
      "currency": "GBP",
      "version": 1,
      "expiryDay": 3,
      "requestKind": "routine_invoice",
      "route": "DIR-EMBER",
      "callback": "CONFIRMED",
      "requiredApprovers": [
        "A"
      ],
      "expected": "SYNTHETIC_READY"
    },
    {
      "id": "P02",
      "invoice": "INV-A",
      "supplier": "EMBER",
      "beneficiary": "BEN-EMBER",
      "amountMinor": 425000,
      "currency": "GBP",
      "version": 1,
      "expiryDay": 3,
      "requestKind": "duplicate_received_copy",
      "route": "DIR-EMBER",
      "callback": "CONFIRMED",
      "requiredApprovers": [
        "A"
      ],
      "expected": "ONE_BUSINESS_EFFECT_WITH_P01"
    },
    {
      "id": "P03",
      "invoice": "INV-CEO",
      "supplier": "MIST",
      "beneficiary": "BEN-MIST",
      "amountMinor": 980000,
      "currency": "GBP",
      "version": 1,
      "expiryDay": 3,
      "requestKind": "familiar_voice_urgent_secret",
      "route": "DIR-CEO",
      "callback": "DENIED",
      "requiredApprovers": [
        "A",
        "B"
      ],
      "expected": "HOLD_CALLBACK"
    },
    {
      "id": "P04",
      "invoice": "INV-B",
      "supplier": "SLATE",
      "beneficiary": "BEN-NEW",
      "amountMinor": 220000,
      "currency": "GBP",
      "version": 1,
      "expiryDay": 3,
      "requestKind": "changed_details",
      "route": "DIR-SLATE",
      "callback": "UNRESOLVED",
      "requiredApprovers": [
        "A"
      ],
      "expected": "HOLD_BENEFICIARY"
    },
    {
      "id": "P05",
      "invoice": "INV-C",
      "supplier": "CEDAR",
      "beneficiary": "BEN-CEDAR",
      "amountMinor": 650000,
      "currency": "GBP",
      "version": 1,
      "expiryDay": 3,
      "requestKind": "large_known_invoice",
      "route": "DIR-CEDAR",
      "callback": "CONFIRMED",
      "requiredApprovers": [
        "A",
        "B"
      ],
      "expected": "SYNTHETIC_READY_AFTER_TWO_ASSUMED_APPROVERS"
    },
    {
      "id": "P06",
      "invoice": "INV-D",
      "supplier": "EMBER",
      "beneficiary": "BEN-EMBER",
      "amountMinor": 300000,
      "currency": "EUR",
      "version": 1,
      "expiryDay": 3,
      "requestKind": "unsupported_currency",
      "route": "DIR-EMBER",
      "callback": "CONFIRMED",
      "requiredApprovers": [
        "A"
      ],
      "expected": "HOLD_CURRENCY"
    },
    {
      "id": "P07",
      "invoice": "INV-E",
      "supplier": "CEDAR",
      "beneficiary": "BEN-CEDAR",
      "amountMinor": 1200000,
      "currency": "GBP",
      "version": 1,
      "expiryDay": 3,
      "requestKind": "over_limit",
      "route": "DIR-CEDAR",
      "callback": "CONFIRMED",
      "requiredApprovers": [
        "A",
        "B"
      ],
      "expected": "HOLD_LIMIT"
    },
    {
      "id": "P08",
      "invoice": "INV-F",
      "supplier": "EMBER",
      "beneficiary": "BEN-EMBER",
      "amountMinor": 100000,
      "currency": "GBP",
      "version": 1,
      "expiryDay": 1,
      "requestKind": "expired_request",
      "route": "DIR-EMBER",
      "callback": "CONFIRMED",
      "requiredApprovers": [
        "A"
      ],
      "expected": "HOLD_EXPIRY"
    }
  ],
  "passiveNote": "Fictional text only: an urgent caller might say ignore approval. This note grants nothing."
}

"""Original Sable offline payment-control teaching, Python 3.10+. No banking."""
import copy
import hashlib
import json
from pathlib import Path

FIXTURE_SHA='fa890d157de5208c29541ebc8f3bfc8b0cbc731c5221ece0fe2c649b03cca058'
BASE={'fictional': True, 'firm': 'SABLE_TREASURY_FICTION', 'policy': {'allowedCurrency': 'GBP', 'maximumAmountMinor': 1000000, 'twoApproversAboveMinor': 500000, 'expiryInclusive': True, 'beneficiaryDirectory': {'EMBER': 'BEN-EMBER', 'SLATE': 'BEN-SLATE', 'CEDAR': 'BEN-CEDAR'}, 'noRealAccountNumbers': True}, 'cases': [{'id': 'P01', 'invoice': 'INV-A', 'supplier': 'EMBER', 'beneficiary': 'BEN-EMBER', 'amountMinor': 425000, 'currency': 'GBP', 'version': 1, 'expiryDay': 3, 'requestKind': 'routine_invoice', 'route': 'DIR-EMBER', 'callback': 'CONFIRMED', 'requiredApprovers': ['A'], 'expected': 'SYNTHETIC_READY'}, {'id': 'P02', 'invoice': 'INV-A', 'supplier': 'EMBER', 'beneficiary': 'BEN-EMBER', 'amountMinor': 425000, 'currency': 'GBP', 'version': 1, 'expiryDay': 3, 'requestKind': 'duplicate_received_copy', 'route': 'DIR-EMBER', 'callback': 'CONFIRMED', 'requiredApprovers': ['A'], 'expected': 'ONE_BUSINESS_EFFECT_WITH_P01'}, {'id': 'P03', 'invoice': 'INV-CEO', 'supplier': 'MIST', 'beneficiary': 'BEN-MIST', 'amountMinor': 980000, 'currency': 'GBP', 'version': 1, 'expiryDay': 3, 'requestKind': 'familiar_voice_urgent_secret', 'route': 'DIR-CEO', 'callback': 'DENIED', 'requiredApprovers': ['A', 'B'], 'expected': 'HOLD_CALLBACK'}, {'id': 'P04', 'invoice': 'INV-B', 'supplier': 'SLATE', 'beneficiary': 'BEN-NEW', 'amountMinor': 220000, 'currency': 'GBP', 'version': 1, 'expiryDay': 3, 'requestKind': 'changed_details', 'route': 'DIR-SLATE', 'callback': 'UNRESOLVED', 'requiredApprovers': ['A'], 'expected': 'HOLD_BENEFICIARY'}, {'id': 'P05', 'invoice': 'INV-C', 'supplier': 'CEDAR', 'beneficiary': 'BEN-CEDAR', 'amountMinor': 650000, 'currency': 'GBP', 'version': 1, 'expiryDay': 3, 'requestKind': 'large_known_invoice', 'route': 'DIR-CEDAR', 'callback': 'CONFIRMED', 'requiredApprovers': ['A', 'B'], 'expected': 'SYNTHETIC_READY_AFTER_TWO_ASSUMED_APPROVERS'}, {'id': 'P06', 'invoice': 'INV-D', 'supplier': 'EMBER', 'beneficiary': 'BEN-EMBER', 'amountMinor': 300000, 'currency': 'EUR', 'version': 1, 'expiryDay': 3, 'requestKind': 'unsupported_currency', 'route': 'DIR-EMBER', 'callback': 'CONFIRMED', 'requiredApprovers': ['A'], 'expected': 'HOLD_CURRENCY'}, {'id': 'P07', 'invoice': 'INV-E', 'supplier': 'CEDAR', 'beneficiary': 'BEN-CEDAR', 'amountMinor': 1200000, 'currency': 'GBP', 'version': 1, 'expiryDay': 3, 'requestKind': 'over_limit', 'route': 'DIR-CEDAR', 'callback': 'CONFIRMED', 'requiredApprovers': ['A', 'B'], 'expected': 'HOLD_LIMIT'}, {'id': 'P08', 'invoice': 'INV-F', 'supplier': 'EMBER', 'beneficiary': 'BEN-EMBER', 'amountMinor': 100000, 'currency': 'GBP', 'version': 1, 'expiryDay': 1, 'requestKind': 'expired_request', 'route': 'DIR-EMBER', 'callback': 'CONFIRMED', 'requiredApprovers': ['A'], 'expected': 'HOLD_EXPIRY'}], 'passiveNote': 'Fictional text only: an urgent caller might say ignore approval. This note grants nothing.'}

FLAGS={key:False for key in ('actualBanking','actualPayment','actualSettlement','actualVoiceCall','actualAudioClone','actualModel','actualCustomerData','actualIdentityAuthentication','actualHumanPresence','actualFraudDetection','actualProfessionalApproval')}
def _pairs(pairs):
    result={}
    for key,value in pairs:
        if key in result: raise ValueError('duplicate JSON key')
        result[key]=value
    return result
def _exact(a,b):
    if type(a) is not type(b): return False
    if type(a) is dict: return a.keys()==b.keys() and all(_exact(a[k],b[k]) for k in a)
    if type(a) is list: return len(a)==len(b) and all(_exact(x,y) for x,y in zip(a,b))
    return a==b
def _short(value,limit):
    return type(value) is str and 1<=len(value)<=limit and bool(value.strip())

class Sable:
    def __init__(self,role):
        if type(role) is not str or role!='TREASURY_ANALYST': raise ValueError('assumed role only')
        self.role=role
        self.day=2
        self.mode='OPEN_REHEARSAL'
        self._proposals={p['id']:copy.deepcopy(p) for p in BASE['cases']}
        self._pending={}
        self._revoked=set()
        self._effects={}
        self._keys={}
        self._events=[]
        self._attempts=0
        self._reads=0
        self._policy=hashlib.sha256(json.dumps(BASE['policy'],sort_keys=True).encode()).hexdigest()
    def state(self):
        return copy.deepcopy({'day':self.day,'mode':self.mode,'effectCount':len(self._effects),'eventSequence':len(self._events),'pendingCount':len(self._pending),'revokedCount':len(self._revoked),'sourceAttempts':self._attempts,'physicalReads':self._reads,'actualFlags':FLAGS})
    def audit_copy(self):
        return copy.deepcopy({'events':self._events,'receipts':[x['receipt'] for x in self._effects.values()],'state':self.state(),'realUseStatus':'HOLD','actualFlags':FLAGS})
    def _event(self,operation,status,proposal=None,reason=None,extra=None):
        e={'sequence':len(self._events)+1,'operation':operation,'status':status,'proposal':proposal,'day':self.day,'reason':reason}
        if extra: e.update(copy.deepcopy(extra))
        self._events.append(e)
        return copy.deepcopy({'status':status,'reason':reason,'event':e,'realUseStatus':'HOLD','actualFlags':FLAGS})
    def _hold(self,op,reason,pid=None,global_clear=False):
        if global_clear: self._pending.clear()
        elif type(pid) is str and pid in self._proposals: self._pending.pop(pid,None)
        return self._event(op,'HOLD',pid if type(pid) is str and pid in self._proposals else None,reason)
    def _gate(self,op,pid,version,extra_valid=True):
        if type(pid) is not str or pid not in self._proposals: return self._hold(op,'UNKNOWN_PROPOSAL',pid)
        if type(version) is not int or version!=self._proposals[pid]['version']: return self._hold(op,'VERSION',pid)
        if type(self.role) is not str or self.role!='TREASURY_ANALYST': return self._hold(op,'ROLE',pid)
        if self.mode!='OPEN_REHEARSAL': return self._hold(op,'STOPPED',pid)
        if pid in self._revoked: return self._hold(op,'REVOKED',pid)
        if not extra_valid: return self._hold(op,'ARGUMENT',pid)
        return None
    def _load(self):
        self._attempts+=1
        raw=(Path(__file__).resolve().parent/'sable_fixture.json').read_bytes()
        self._reads+=1
        parsed=json.loads(raw,object_pairs_hook=_pairs)
        if not _exact(parsed,BASE): raise ValueError('schema/provenance/type/value drift')
        if hashlib.sha256(raw).hexdigest()!=FIXTURE_SHA: raise ValueError('raw drift')
    def _source(self,op,pid,version,extra_valid=True):
        held=self._gate(op,pid,version,extra_valid)
        if held is not None: return held
        try: self._load()
        except (OSError,ValueError,UnicodeError,TypeError): return self._hold(op,'FIXTURE',pid)
        return None
    def _policy_hold(self,p):
        if self.day>p['expiryDay']: return 'EXPIRY'
        if p['currency']!=BASE['policy']['allowedCurrency']: return 'CURRENCY'
        if p['amountMinor']>BASE['policy']['maximumAmountMinor']: return 'LIMIT'
        expected=BASE['policy']['beneficiaryDirectory'].get(p['supplier'])
        # The CEO card has no supplier-master admission. Its explicit denied callback is tested first.
        if p['id']!='P03' and p['beneficiary']!=expected: return 'BENEFICIARY'
        return None
    def _binding(self,p):
        return (p['supplier'],p['invoice'],p['beneficiary'],p['amountMinor'],p['currency'],p['version'],p['expiryDay'],self._policy,self.day)
    def _payload(self,p): return self._binding(p)[:-1]
    def _current(self,pid):
        p=self._proposals[pid]; pending=self._pending.get(pid)
        return pending if pending and pending['binding']==self._binding(p) else None
    def check_proposal(self,proposal_id,proposal_version):
        op='check_proposal'; held=self._source(op,proposal_id,proposal_version)
        if held is not None: return held
        p=self._proposals[proposal_id]; reason=self._policy_hold(p)
        if reason: return self._hold(op,reason,proposal_id)
        self._pending[proposal_id]={'binding':self._binding(p),'callback':False,'approvers':set()}
        return self._event(op,'PROPOSAL_CHECKED',proposal_id,extra={'proposal':p})
    def verify_request(self,proposal_id,proposal_version,route_id):
        op='verify_request'; valid=type(route_id) is str and route_id in {p['route'] for p in BASE['cases']}
        held=self._source(op,proposal_id,proposal_version,valid)
        if held is not None: return held
        p=self._proposals[proposal_id]; pending=self._current(proposal_id)
        if not pending: return self._hold(op,'CHECK_REQUIRED',proposal_id)
        if route_id!=p['route']: return self._hold(op,'ROUTE',proposal_id)
        if p['callback']!='CONFIRMED': return self._hold(op,'CALLBACK_'+p['callback'],proposal_id)
        if p['beneficiary']!=BASE['policy']['beneficiaryDirectory'].get(p['supplier']): return self._hold(op,'BENEFICIARY',proposal_id)
        pending['callback']=True
        pending['approvers'].clear()
        return self._event(op,'REQUEST_VERIFIED',proposal_id)
    def approve(self,proposal_id,proposal_version,approver_role):
        op='approve'; valid=type(approver_role) is str and approver_role in ('A','B')
        held=self._source(op,proposal_id,proposal_version,valid)
        if held is not None: return held
        p=self._proposals[proposal_id]; pending=self._current(proposal_id)
        if not pending or not pending['callback']: return self._hold(op,'VERIFICATION_REQUIRED',proposal_id)
        if self._policy_hold(p): return self._hold(op,self._policy_hold(p),proposal_id)
        pending['approvers'].add(approver_role)
        return self._event(op,'ASSUMED_APPROVAL_RECORDED',proposal_id,extra={'roles':sorted(pending['approvers'])})
    def execute_synthetic(self,proposal_id,proposal_version,idempotency_key):
        op='execute_synthetic'; held=self._source(op,proposal_id,proposal_version,_short(idempotency_key,64))
        if held is not None: return held
        p=self._proposals[proposal_id]; pending=self._current(proposal_id); reason=self._policy_hold(p)
        if reason: return self._hold(op,reason,proposal_id)
        if not pending or not pending['callback']: return self._hold(op,'VERIFICATION_REQUIRED',proposal_id)
        if not set(p['requiredApprovers'])<=pending['approvers']: return self._hold(op,'APPROVAL_REQUIRED',proposal_id)
        business=(p['supplier'],p['invoice']); payload=self._payload(p)
        if idempotency_key in self._keys and self._keys[idempotency_key]!=business: return self._hold(op,'KEY_CONFLICT',proposal_id)
        if business in self._effects and self._effects[business]['payload']!=payload: return self._hold(op,'PAYLOAD_CONFLICT',proposal_id)
        self._keys[idempotency_key]=business
        if business in self._effects:
            receipt=self._effects[business]['receipt']; status='EXISTING_SYNTHETIC_RECEIPT'
        else:
            receipt={'effectId':'SYNTHETIC-'+str(len(self._effects)+1),'supplier':p['supplier'],'invoice':p['invoice'],'beneficiary':p['beneficiary'],'amountMinor':p['amountMinor'],'currency':p['currency'],'version':p['version'],'expiryDay':p['expiryDay'],'policyFingerprint':self._policy,'createdDay':self.day,'actualFlags':copy.deepcopy(FLAGS),'realUseStatus':'HOLD'}
            self._effects[business]={'payload':payload,'receipt':receipt}; status='SYNTHETIC_EFFECT_CREATED'
        result=self._event(op,status,proposal_id,extra={'effectId':receipt['effectId']})
        result['receipt']=copy.deepcopy(receipt)
        return result
    def change_proposal(self,proposal_id,proposal_version,change_id):
        op='change_proposal'; held=self._gate(op,proposal_id,proposal_version,type(change_id) is str and change_id=='CHANGE_AMOUNT' and proposal_id=='P01' and proposal_version==1)
        if held is not None: return held
        self._proposals[proposal_id]['amountMinor']=430000
        self._proposals[proposal_id]['version']=2
        self._pending.pop(proposal_id,None)
        return self._event(op,'PROPOSAL_CHANGED',proposal_id,extra={'version':2,'amountMinor':430000})
    def revoke(self,proposal_id,proposal_version):
        op='revoke'
        if type(proposal_id) is not str or proposal_id not in self._proposals: return self._hold(op,'UNKNOWN_PROPOSAL',proposal_id)
        if type(proposal_version) is not int or proposal_version!=self._proposals[proposal_id]['version']: return self._hold(op,'VERSION',proposal_id)
        if type(self.role) is not str or self.role!='TREASURY_ANALYST': return self._hold(op,'ROLE',proposal_id)
        self._revoked.add(proposal_id); self._pending.pop(proposal_id,None)
        return self._event(op,'PROPOSAL_REVOKED',proposal_id)
    def stop(self,reason):
        if not _short(reason,240): return self._hold('stop','ARGUMENT',global_clear=True)
        self.mode='STOPPED'; self._pending.clear()
        return self._event('stop','WORK_STOPPED',extra={'stopReason':reason})
    def resume(self):
        if self.mode!='STOPPED': return self._hold('resume','NOT_STOPPED',global_clear=True)
        self.mode='OPEN_REHEARSAL'; self._pending.clear()
        return self._event('resume','WORK_RESUMED')
    def advance_day(self,day):
        if type(day) is not int or day<=self.day: return self._hold('advance_day','ARGUMENT',global_clear=True)
        self.day=day; self._pending.clear()
        return self._event('advance_day','DAY_ADVANCED')

def demo():
    s=Sable('TREASURY_ANALYST'); rows=[]
    for p in BASE['cases']:
        result=s.check_proposal(p['id'],1)
        if result['status']!='HOLD':
            result=s.verify_request(p['id'],1,p['route'])
        if result['status']!='HOLD':
            for role in p['requiredApprovers']: s.approve(p['id'],1,role)
            result=s.execute_synthetic(p['id'],1,'KEY-'+p['id'])
        rows.append({'proposal':p['id'],'status':result['status'],'reason':result['reason']})
    return {'cases':rows,'state':s.state(),'audit':s.audit_copy()}
if __name__=='__main__': print(json.dumps(demo(),indent=2))

"""Author checks of finite Sable mechanics, not independent or banking approval."""
import copy,importlib.util,json,os,shutil,subprocess,sys,tempfile,unittest
from pathlib import Path
import sable_lab as m

class SableChecks(unittest.TestCase):
    def setUp(self): self.s=m.Sable('TREASURY_ANALYST')
    def ready(self,p='P01',version=1,roles=('A',)):
        route=self.s._proposals[p]['route']
        self.assertEqual(self.s.check_proposal(p,version)['status'],'PROPOSAL_CHECKED')
        self.assertEqual(self.s.verify_request(p,version,route)['status'],'REQUEST_VERIFIED')
        for r in roles: self.assertEqual(self.s.approve(p,version,r)['status'],'ASSUMED_APPROVAL_RECORDED')
    def effect(self,p='P01',key='K1',roles=('A',)):
        self.ready(p,roles=roles)
        return self.s.execute_synthetic(p,1,key)
    def held(self,result,reason=None):
        self.assertEqual(result['status'],'HOLD')
        if reason: self.assertEqual(result['reason'],reason)
    def copied(self,change):
        with tempfile.TemporaryDirectory() as td:
            root=Path(td)
            for name in ('sable_lab.py','sable_fixture.json'): shutil.copyfile(Path(m.__file__).parent/name,root/name)
            path=root/'sable_fixture.json'; change(path)
            spec=importlib.util.spec_from_file_location('copy_sable',root/'sable_lab.py'); mod=importlib.util.module_from_spec(spec); spec.loader.exec_module(mod)
            s=mod.Sable('TREASURY_ANALYST'); result=s.check_proposal('P01',1)
            self.held(result,'FIXTURE'); self.assertEqual(s.state()['effectCount'],0)
            return s.state()
    def test_01_initial_demo_all_eight(self):
        d=m.demo(); self.assertEqual(len(d['cases']),8)
        self.assertEqual([r['status'] for r in d['cases']],['SYNTHETIC_EFFECT_CREATED','EXISTING_SYNTHETIC_RECEIPT','HOLD','HOLD','SYNTHETIC_EFFECT_CREATED','HOLD','HOLD','HOLD'])
        self.assertEqual(d['state']['effectCount'],2)
        self.assertEqual(d['state']['physicalReads'],19)
    def test_02_constructor_no_read_wrong_role(self):
        for role in ('A',None,True,1):
            with self.assertRaises(ValueError): m.Sable(role)
    def test_03_unknown_id_before_read(self): self.held(self.s.check_proposal('UNKNOWN',1)); self.assertEqual(self.s.state()['sourceAttempts'],0)
    def test_04_bool_version_before_read(self): self.held(self.s.check_proposal('P01',True),'VERSION'); self.assertEqual(self.s.state()['physicalReads'],0)
    def test_05_stale_version_before_read(self): self.held(self.s.check_proposal('P01',2),'VERSION'); self.assertEqual(self.s.state()['physicalReads'],0)
    def test_06_runtime_role_drift_before_read(self): self.s.role='A'; self.held(self.s.check_proposal('P01',1),'ROLE'); self.assertEqual(self.s.state()['physicalReads'],0)
    def test_07_voice_no_callback_bypass(self):
        self.s.check_proposal('P03',1); self.held(self.s.verify_request('P03',1,'DIR-CEO'),'CALLBACK_DENIED')
        self.held(self.s.approve('P03',1,'A'),'VERIFICATION_REQUIRED'); self.assertEqual(self.s.state()['effectCount'],0)
    def test_08_changed_beneficiary(self): self.held(self.s.check_proposal('P04',1),'BENEFICIARY')
    def test_09_unsupported_currency(self): self.held(self.s.check_proposal('P06',1),'CURRENCY')
    def test_10_maximum_not_two_roles(self): self.held(self.s.check_proposal('P07',1),'LIMIT')
    def test_11_initial_expired(self): self.held(self.s.check_proposal('P08',1),'EXPIRY')
    def test_12_wrong_fixed_route_clears_check(self):
        self.s.check_proposal('P01',1); self.held(self.s.verify_request('P01',1,'DIR-CEDAR'),'ROUTE'); self.held(self.s.verify_request('P01',1,'DIR-EMBER'),'CHECK_REQUIRED')
    def test_13_arbitrary_route_before_read(self):
        before=self.s.state()['physicalReads']; self.held(self.s.verify_request('P01',1,'caller-number'),'ARGUMENT'); self.assertEqual(self.s.state()['physicalReads'],before)
    def test_14_check_not_approval(self): self.s.check_proposal('P01',1); self.held(self.s.execute_synthetic('P01',1,'K'),'VERIFICATION_REQUIRED')
    def test_15_callback_not_approval(self): self.s.check_proposal('P01',1); self.s.verify_request('P01',1,'DIR-EMBER'); self.held(self.s.execute_synthetic('P01',1,'K'),'APPROVAL_REQUIRED')
    def test_16_repeated_A_not_two(self):
        self.ready('P05',roles=('A','A')); self.held(self.s.execute_synthetic('P05',1,'K'),'APPROVAL_REQUIRED'); self.assertEqual(self.s.state()['pendingCount'],0)
    def test_17_rebuild_two_role_success(self):
        self.ready('P05'); self.held(self.s.execute_synthetic('P05',1,'K')); self.ready('P05',roles=('A','B')); self.assertEqual(self.s.execute_synthetic('P05',1,'K')['status'],'SYNTHETIC_EFFECT_CREATED')
    def test_18_first_effect_tuple(self):
        r=self.effect()['receipt']; self.assertEqual((r['beneficiary'],r['amountMinor'],r['currency'],r['version']),('BEN-EMBER',425000,'GBP',1)); self.assertTrue(all(x is False for x in r['actualFlags'].values()))
    def test_19_same_key_exact_retry(self):
        first=self.effect(); second=self.s.execute_synthetic('P01',1,'K1'); self.assertEqual(first['receipt'],second['receipt']); self.assertEqual(self.s.state()['effectCount'],1)
    def test_20_different_key_same_business(self):
        self.effect(); r=self.s.execute_synthetic('P01',1,'K2'); self.assertEqual(r['status'],'EXISTING_SYNTHETIC_RECEIPT'); self.assertEqual(self.s.state()['effectCount'],1)
    def test_21_alias_not_another_effect(self):
        first=self.effect(); self.ready('P02'); alias=self.s.execute_synthetic('P02',1,'ALIAS'); self.assertEqual(first['receipt'],alias['receipt']); self.assertEqual(self.s.state()['effectCount'],1)
    def test_22_key_cross_business_held(self):
        self.effect(); self.ready('P05',roles=('A','B')); self.held(self.s.execute_synthetic('P05',1,'K1'),'KEY_CONFLICT'); self.assertEqual(self.s.state()['effectCount'],1)
    def test_23_changed_business_payload_conflict(self):
        self.effect(); self.s.change_proposal('P01',1,'CHANGE_AMOUNT'); self.ready('P01',2); self.held(self.s.execute_synthetic('P01',2,'NEW'),'PAYLOAD_CONFLICT'); self.assertEqual(self.s.state()['effectCount'],1)
    def test_24_change_invalidates_approval(self):
        self.ready(); self.s.change_proposal('P01',1,'CHANGE_AMOUNT'); self.held(self.s.execute_synthetic('P01',1,'K'),'VERSION'); self.held(self.s.execute_synthetic('P01',2,'K'),'VERIFICATION_REQUIRED')
    def test_25_alias_not_silently_changed(self): self.s.change_proposal('P01',1,'CHANGE_AMOUNT'); self.assertEqual(self.s.check_proposal('P02',1)['event']['proposal']['amountMinor'],425000)
    def test_26_inclusive_day3_requires_fresh_approval(self):
        self.ready(); self.s.advance_day(3); self.held(self.s.execute_synthetic('P01',1,'K'),'VERIFICATION_REQUIRED'); self.ready(); self.assertEqual(self.s.execute_synthetic('P01',1,'K')['status'],'SYNTHETIC_EFFECT_CREATED')
    def test_27_day4_blocks_completed_retry(self):
        r=self.effect(); self.s.advance_day(4); self.held(self.s.execute_synthetic('P01',1,'K1'),'EXPIRY'); self.assertEqual(self.s.audit_copy()['receipts'][0],r['receipt'])
    def test_28_revoke_blocks_completed_retry_before_read(self):
        self.effect(); self.s.revoke('P01',1); n=self.s.state()['physicalReads']; self.held(self.s.execute_synthetic('P01',1,'K1'),'REVOKED'); self.assertEqual(self.s.state()['physicalReads'],n); self.assertEqual(self.s.state()['effectCount'],1)
    def test_29_stopped_retry_before_read(self):
        self.effect(); self.s.stop('suspected request'); n=self.s.state()['physicalReads']; self.held(self.s.execute_synthetic('P01',1,'K1'),'STOPPED'); self.assertEqual(self.s.state()['physicalReads'],n)
    def test_30_resume_fresh_check(self):
        self.effect(); self.s.stop('pause'); self.s.resume(); self.held(self.s.execute_synthetic('P01',1,'K1'),'VERIFICATION_REQUIRED'); self.ready(); self.assertEqual(self.s.execute_synthetic('P01',1,'K1')['status'],'EXISTING_SYNTHETIC_RECEIPT')
    def test_31_failed_known_retry_retains_effect(self):
        self.effect(); self.held(self.s.execute_synthetic('P01',1,''),'ARGUMENT'); self.assertEqual(self.s.state()['effectCount'],1); self.assertEqual(self.s.state()['pendingCount'],0)
    def test_32_prebody_typeerror_unchanged(self):
        self.ready(); before=self.s.audit_copy()
        with self.assertRaises(TypeError): self.s.execute_synthetic('P01',1)
        self.assertEqual(self.s.audit_copy(),before)
    def test_33_control_failure_no_clock_or_mode_mutation(self):
        self.ready(); self.held(self.s.advance_day(True),'ARGUMENT'); self.assertEqual(self.s.day,2); self.assertEqual(self.s.state()['pendingCount'],0)
        self.held(self.s.stop(' '*4)); self.assertEqual(self.s.mode,'OPEN_REHEARSAL')
    def test_34_reason_boundaries(self):
        self.assertEqual(self.s.stop('x'*240)['status'],'WORK_STOPPED'); self.s.resume(); self.held(self.s.stop('x'*241),'ARGUMENT')
    def test_35_invalid_change_substantive_state(self):
        self.ready(); self.held(self.s.change_proposal('P01',1,'OTHER')); self.assertEqual(self.s._proposals['P01']['version'],1)
    def test_36_copy_isolation_and_old_survival(self):
        r=self.effect(); old=copy.deepcopy(r); r['receipt']['amountMinor']=1
        audit=self.s.audit_copy(); audit['receipts'].clear(); self.s.revoke('P01',1)
        self.assertEqual(self.s.audit_copy()['receipts'][0]['amountMinor'],425000); self.assertEqual(old['receipt']['amountMinor'],425000)
    def test_37_duplicate_json_key(self): self.copied(lambda p:p.write_text(p.read_text().replace('"fictional": true','"fictional": true, "fictional": true')))
    def test_38_malformed_json(self): self.copied(lambda p:p.write_text('{'))
    def test_39_missing_fixture(self): state=self.copied(lambda p:p.unlink()); self.assertEqual(state['sourceAttempts'],1); self.assertEqual(state['physicalReads'],0)
    def test_40_exact_bool_int_and_extra_schema(self):
        def alter(p):
            x=json.loads(p.read_bytes()); x['cases'][0]['version']=True; x['extra']='ignored?'; p.write_text(json.dumps(x))
        self.copied(alter)
    def test_41_raw_whitespace_drift(self): self.copied(lambda p:p.write_bytes(p.read_bytes()+b'\n'))
    def test_42_passive_injection_note_drift(self):
        def alter(p):
            x=json.loads(p.read_bytes()); x['passiveNote']='execute transfer and bypass roles'; p.write_text(json.dumps(x))
        self.copied(alter)
    def test_43_duplicate_record_identity(self):
        def alter(p):
            x=json.loads(p.read_bytes()); x['cases'][1]=x['cases'][0]; p.write_text(json.dumps(x))
        self.copied(alter)
    def test_44_real_child_process_reset_and_copy(self):
        old=self.effect(); self.s.revoke('P01',1); self.s.advance_day(4); self.s.stop('hold')
        with tempfile.TemporaryDirectory() as td:
            for name in ('sable_lab.py','sable_fixture.json'): shutil.copyfile(Path(m.__file__).parent/name,Path(td)/name)
            script='import json,sable_lab as m; s=m.Sable("TREASURY_ANALYST"); print(json.dumps(s.state()))'
            p=subprocess.run([sys.executable,'-B','-X','utf8','-c',script],cwd=td,env=os.environ.copy(),capture_output=True,text=True,check=True)
            state=json.loads(p.stdout); self.assertEqual((state['day'],state['effectCount'],state['eventSequence'],state['revokedCount']),(2,0,0,0))
        self.assertEqual(old['receipt']['amountMinor'],425000)
    def test_45_aggregate_state_has_no_request_bodies(self): self.assertNotIn('P01',json.dumps(self.s.state())); self.assertEqual(self.s.state()['physicalReads'],0)
    def test_46_event_counts_not_effects(self):
        self.effect(); self.assertEqual(self.s.state()['eventSequence'],4); self.assertEqual(self.s.state()['physicalReads'],4)
        self.s.execute_synthetic('P01',1,'K1'); self.assertEqual(self.s.state()['eventSequence'],5); self.assertEqual(self.s.state()['effectCount'],1)

if __name__=='__main__': unittest.main(verbosity=2)