# Goal: Activate V6 Controlled Aquifer Releases ## Priority and dependency This is the next implementation priority after completion and archival of: - V6 Aquifer Governance, Stewardship, and Release Constitution; - Migration 046; - V6 Development Wallet Capacity, Saturation Policy, and Aquifer Observability; - V6 Development Rootwater Circulation and Expiry; - V6 Development Rain; - V6 Development Membership; - V6 Development Economy. Active constitution: ```text V6-AQUIFER-CONSTITUTION-001 ``` Current verified development baseline: ```text Dataset generation: V6-DEV-2026-08-03-G01 Aquifer mapped balance: 2,511 Copper Rootwater custody liability: 11 Copper Available uncommitted Aquifer value: 2,500 Copper Authorized outflow: 0 Executed release value: 0 Historical classified cache/Ledger delta: 195 Copper ``` The 11-Copper Rootwater custody liability is not releasable Aquifer value. The historical 195-Copper classified cache/Ledger delta must remain visible and untouched. It may not be silently repaired, netted away, or counted as release capacity. Treat the completed governance owners as frozen dependencies: - `AquiferGovernancePolicyService`; - `AquiferProposalService`; - `AquiferProposalEligibilityService`; - `AquiferDecisionService`; - `AquiferAuthorizationService`; - `AquiferPurposeDestinationService`. Do not reopen: - proposal eligibility; - sole Administrator decision authority; - Administrator self-approval; - related-party disclosure; - no reserve floor; - no fixed release schedule; - proposal privacy; - executed-release transparency; - own-contribution visibility; - no leaderboard; - purpose categories; - personal-Wallet destination blocks; - Wardship acceptance and membership activation; - Quest escrow and rewards; - Offering reservation, fulfillment, settlement, cancellation, and refund; - Event authority; - Wallet/Ledger authority; - Aquifer identity; - current inflow classification; - current conservation. This goal activates actual purpose-bound Aquifer Ledger outflow only inside the recognized disposable development dataset. It does not activate public-production release, external payments, cash withdrawal, Harvest, broad Drift, Convergence, or unrestricted personal grants. --- # Purpose At completion: 1. only an approved active Aquifer authorization may be executed; 2. execution revalidates the active constitution; 3. execution revalidates the purpose destination; 4. execution revalidates the authorization ceiling; 5. execution revalidates current available uncommitted Aquifer value; 6. execution creates one immutable Aquifer release; 7. execution moves value only into a purpose-bound contract or escrow; 8. execution never credits an unrestricted personal Wallet; 9. execution never credits an Administrator personal Wallet; 10. every release creates a public/member-visible release record; 11. private proposal deliberation may remain private; 12. executed releases may never remain private; 13. every release tracks authorized, committed, used, remaining, returned, reversed, and closed amounts; 14. unused value returns through compensating Ledger history; 15. original outflow history is never deleted or rewritten; 16. release execution is exactly-once; 17. release closeout is exactly-once; 18. cumulative releases never exceed the authorization ceiling; 19. cumulative releases never oversubscribe available Aquifer value; 20. onboarding Wardship campaigns are the first complete release path; 21. individual Wardships are supported; 22. House Wardships are supported; 23. Quest reward-pool releases are supported through canonical Quest escrow; 24. Offering releases are supported through canonical Offering lifecycle; 25. Event releases are supported through bounded Event-purpose programs; 26. public infrastructure is supported only through a bounded public-purpose contract; 27. corrective releases are supported only through an existing correction owner; 28. beneficiaries receive value only through the approved purpose contract; 29. related-party disclosure follows the authorization into the release; 30. members can see release status and public accounting; 31. Administrators can operate releases from the existing Aquifer workbench; 32. Aquifer conservation remains exact; 33. Rootwater custody remains excluded; 34. the historical classified delta remains unchanged; 35. no external provider call occurs; 36. no production scheduler is activated; 37. no direct Aquifer balance edit is introduced. --- # Locked release doctrine ## Approval and execution remain separate Approval means: > The Administrator authorizes up to a stated ceiling for a specific purpose-bound destination. Approval moves no Coin. Execution means: > The Administrator creates the actual program and commits Aquifer value through the canonical Ledger. Execution requires: - approved authorization; - active authorization state; - remaining authorization amount; - valid destination; - active constitution; - available uncommitted Aquifer value; - exact release amount; - purpose-contract configuration; - public release summary; - closeout rule; - exact confirmation; - idempotency key; - development gates. ## No unrestricted grants Aquifer value may not execute into: - a member personal Wallet; - an Administrator personal Wallet; - an unrestricted Avatar Wallet grant; - an unrestricted House Wallet grant; - an unrestricted Event Wallet grant; - an unrestricted Entity Wallet grant; - company operating revenue; - cash withdrawal; - external-provider payout. Every release enters a purpose-bound contract or escrow. ## Related-party releases Administrators may execute releases benefiting Admin-controlled Houses, Events, Quests, Offerings, Wardship programs, or public-purpose projects. The release must preserve: - proposer; - approving Administrator; - executing Administrator; - destination controllers; - related-party flag; - public disclosure; - purpose; - amount; - used amount; - returned amount; - final status. Related-party status is allowed. Hidden related-party status is blocked. ## No reserve floor There is no mandatory reserve floor. Execution may commit up to current available uncommitted Aquifer value. The workbench must show: - mapped Aquifer balance; - Rootwater custody liability; - governance-authorized but unexecuted amount; - active committed release amount; - available uncommitted amount; - proposed execution amount; - projected available amount afterward. Do not hardcode current balances. ## No fixed schedule Releases execute when the Administrator chooses. There is no automatic seasonal release. Seasonal public campaigns remain optional bounded programs. --- # Correct completion wording Use wording equivalent to: > V6 Controlled Aquifer Releases are active only in the recognized disposable development dataset. Approved Aquifer authorizations can be executed by appointed Administrators into canonical purpose-bound Wardship, Quest, Offering, Event, public-purpose, and bounded-correction contracts. Every release revalidates authorization, available Aquifer value, destination, related-party disclosure, and the active constitution. Execution creates public release records and canonical Ledger history. No release may credit an unrestricted personal Wallet, including an Administrator Wallet. Unused or cancelled value returns through compensating Ledger entries. Onboarding Wardship campaigns are the first complete release path. Aquifer conservation remains exact. External payment, cash withdrawal, Harvest, broad Drift, Convergence, production scheduling, and public-production release remain disabled. Do not call the goal complete if: - release executes without authorization; - approval itself moves Coin; - execution exceeds the authorization ceiling; - cumulative releases oversubscribe the Aquifer; - Rootwater custody liability is spent; - the historical delta is repaired or counted as release capacity; - a personal Wallet can be selected; - an Administrator Wallet can be selected; - a raw Wallet ID can be supplied; - an unrestricted House, Event, or Entity Wallet receives value; - Wardship activation bypasses canonical Wardship acceptance; - Quest release bypasses Quest escrow; - Offering release pays before valid settlement; - Event support lacks a bounded purpose and closeout; - public infrastructure becomes a vague Wallet grant; - corrective release lacks a correction owner; - executed release remains secret; - unused value disappears; - unused value returns to proposer, approver, executor, or destination controller; - Ledger history is deleted or rewritten; - closeout can run twice; - reads move value; - external money moves; - `_v4` or `_v5` changes; - controlled residue remains; - authoritative tests are not green. --- # Read first Inspect the current canonical equivalents of: 1. current command brief; 2. Aquifer Governance completion; 3. Aquifer Governance Constitution; 4. Proposal and Decision contract; 5. Authorization contract; 6. Purpose-Bound Destination contract; 7. Wardship Program contract; 8. Transparency and Member Contribution contract; 9. Aquifer Operations and Observability contract; 10. Wallet/Ledger; 11. Wardship constitution and acceptance; 12. House Wardship contract; 13. membership assignment and standing; 14. Quest escrow, cancellation, and reward; 15. Quest Web funding; 16. Offering claim, reservation, fulfillment, settlement, cancellation, and refund; 17. Event authority and support; 18. public infrastructure planning records from Migration 046; 19. correction and reversal owners; 20. Administrator appointment; 21. current Aquifer workbench; 22. member Aquifer surface; 23. Character Home and Coin Purse; 24. Universal Dex; 25. Console and audit; 26. gates; 27. migrations; 28. Laboratory Aquifer models; 29. reset plan; 30. test inventories; 31. exact safe inventory. Do not create a second Wardship, Quest, Offering, Event, Wallet, or Ledger system. --- # Canonical release owners Create or extend these service boundaries using repository conventions. ## AquiferReleaseService Owns: - preview; - execution; - list/detail; - release status; - amount accounting; - authorization consumption; - public release record; - disclosure propagation; - cancellation; - audit; - Console events; - idempotency. It delegates purpose-specific behavior. ## AquiferReleasePolicyService Owns: - execution eligibility; - constitution revision; - purpose allowlist; - authorization state; - authorization ceiling; - available balance; - Rootwater custody exclusion; - historical-delta exclusion; - destination validation; - public-record requirement; - disclosure requirement; - environment and gates; - stable blocked reasons. ## AquiferReleaseLedgerService Owns Aquifer-side Ledger movement: - purpose-bound outflow; - compensating return; - source/destination mapping; - conservation; - release/Ledger reconciliation. No direct Wallet balance edits. ## AquiferReleaseCloseoutService Owns: - used amount; - active commitments; - unused amount; - return; - cancellation; - expiry; - release completion; - public closeout; - exactly-once closeout. ## Purpose adapters Create the smallest adapters required: ```text AquiferWardshipReleaseService AquiferQuestReleaseService AquiferOfferingReleaseService AquiferEventReleaseService AquiferPublicPurposeReleaseService AquiferCorrectionReleaseService ``` Each adapter must use its canonical domain owner. --- # Release record Every execution creates one immutable release record containing: - release ID; - authorization ID; - proposal ID; - constitution revision; - purpose category; - public title and summary; - private operator notes; - release amount; - authorization ceiling; - amount previously executed; - authorization remaining; - canonical Aquifer owner; - destination type and canonical ID; - destination label and controller; - purpose-contract type and ID; - proposer; - approving Administrator; - executing Administrator; - related-party disclosure; - release status; - committed amount; - used amount; - remaining amount; - returned amount; - release Ledger group; - return Ledger group; - program dates; - review date; - public-record timestamp; - dataset/environment; - idempotency key; - immutable action history. Suggested states: ```text executing active paused fully_used partially_used closing closed cancelled failed_recoverable reversed ``` Use established repository vocabulary when available. No release record may be deleted after execution. --- # Common execution flow Every release: 1. loads and locks authorization; 2. loads active constitution; 3. revalidates purpose; 4. revalidates destination; 5. recomputes related-party disclosure; 6. reads canonical Aquifer balance; 7. excludes Rootwater custody liability; 8. excludes active committed release value; 9. validates execution amount against authorization remaining; 10. validates execution amount against available uncommitted value; 11. builds purpose-contract preview; 12. builds public release summary; 13. requires exact confirmation; 14. reserves idempotent release action; 15. creates release record; 16. creates or activates purpose contract; 17. posts canonical Aquifer Ledger outflow; 18. links release, authorization, purpose contract, and Ledger group; 19. publishes public/member release record; 20. completes action; 21. refreshes Aquifer accounting. Use an explicit retry-safe staged coordinator when one transaction cannot span domain owners. Suggested confirmations: ```text EXECUTE AQUIFER RELEASE PAUSE AQUIFER PROGRAM CLOSE AQUIFER PROGRAM RETURN UNUSED AQUIFER VALUE CANCEL AQUIFER RELEASE RETRY AQUIFER RELEASE ``` --- # Authorization accounting An authorization may permit: - one full release; - several partial releases; - campaign draws. Track: ```text authorized ceiling executed total cancelled total remaining executable amount ``` Never exceed the ceiling. Approved authorization is governance commitment. Executed release is Ledger commitment. Do not double subtract the same amount as both unexecuted authorization and active release commitment. --- # Public release records Every executed release becomes visible to members. Show: - title; - purpose category; - amount released; - destination object; - public purpose; - approval date; - execution date; - status; - amount used; - active committed amount; - remaining amount; - returned amount; - related-party disclosure in member-safe form; - campaign dates; - closeout result. Do not expose: - private proposal notes; - private beneficiary details; - unnecessary Account data; - raw Wallet or Ledger IDs as primary UX. The record remains visible after cancellation, return, closeout, or reversal. --- # First required activation: onboarding Wardship campaign This is the first mandatory complete release path. ## Campaign record An approved campaign records: - campaign ID; - release ID; - title; - onboarding purpose; - allowed tier or tier set; - quantity; - current/next unpaid-season rule; - beneficiary eligibility; - named-beneficiary or open-campaign mode; - attribution; - per-beneficiary limit; - opening and closing date; - issuance method; - acceptance/redeem requirement; - unit policy amount; - total committed amount; - issued count; - accepted count; - redeemed count; - cancelled count; - unused amount; - returned amount; - status. Use the constitutional quantity limit. ## Funding behavior Aquifer release value becomes purpose-bound Wardship campaign capacity. When a Wardship is issued: - create canonical Wardship issuance; - link campaign and release; - preserve Aquifer sponsor provenance; - do not credit beneficiary Wallet. When accepted/redeemed: - activate membership through canonical owners; - consume the campaign unit; - preserve privacy; - update public aggregate counts. When cancelled, expired, duplicated, or invalid: - release unused campaign capacity; - preserve history; - do not delete accepted membership terms. ## Required retained operator-play campaign Create one bounded retained development campaign through canonical paths: - one approved Admin proposal; - one authorization; - one executed onboarding campaign; - at least three Wardships; - at least two accepted by ordinary development Accounts; - at least one unused/cancelled unit returned at closeout; - one public release record; - exact Aquifer reconciliation; - no beneficiary Wallet credit; - no external payment. --- # Individual Wardship release Validate: - beneficiary or beneficiary rule; - tier; - current/next unpaid season; - acceptance; - attribution; - amount ceiling; - duplicate coverage; - standing and queue rules. Execution creates a canonical Aquifer-funded Wardship. No personal Wallet transfer. Unused or cancelled authorization returns. --- # House Wardship release Validate: - House; - current leader/operator; - House standing; - target season; - acceptance by current leader; - no governance rights granted by funding; - no direct House Wallet transfer; - succession rules; - return rule. Execution uses canonical House Wardship activation. --- # Quest release Aquifer value enters canonical Quest escrow. It may not enter issuer, beneficiary, House, or Administrator Wallets as unrestricted Coin. Validate: - Quest or approved staged Quest; - issuer/beneficiary; - reward amount; - completion capacity; - required escrow; - current escrow; - release amount; - authorization ceiling; - Quest status; - cancellation and return mapping. Aquifer is recorded as sponsor/source. Participants receive ordinary Coin through existing reward routing. On cancellation: - paid rewards remain; - unused Aquifer-funded escrow returns to the Aquifer; - return uses compensating Ledger history. Public accounting shows released escrow, rewards paid, remaining escrow, return, completions, and status. --- # Offering release Activate only currently proven Offering modes. Safe patterns: 1. Aquifer-sponsored purchase/support pool; 2. milestone or fulfillment support. Do not pay the controller when the release executes. Validate: - Offering; - controller; - mode; - public-benefit purpose; - claim/support limit; - fulfillment; - settlement; - refund; - closeout; - related-party disclosure. Create a purpose-bound Offering pool or reservation. Recipient receives ordinary Coin only through canonical settlement. Unused, cancelled, refunded, or expired value returns according to Offering lifecycle. --- # Event release Event support must be bounded. Allowed examples: - onboarding Wardships; - Event Quest pools; - approved Event Offerings; - public participation infrastructure; - accessibility/shared operations represented by bounded contracts. Do not execute a generic Event Wallet transfer. Create or extend one Event-support program recording: - Event; - governing House/Entity; - operator; - purpose; - amount; - allowed child uses; - dates; - used; - remaining; - return rule; - public summary; - closeout. Child uses must be canonical Wardship, Quest, Offering, or public-purpose contracts. --- # Public infrastructure/public goods Activate only through a bounded public-purpose contract recording: - public purpose; - operator; - related entities; - amount ceiling; - permitted disbursement actions; - prohibited destinations; - program term; - milestone/fulfillment evidence; - used; - remaining; - closeout; - public report; - unused return. No arbitrary Wallet reimbursements. When safe execution cannot be represented without raw Wallet payments, report this path unavailable while completing the safe Wardship, Quest, Offering, and Event paths. --- # Bounded corrective release Execute only when: - a real failed/blocked obligation exists; - the canonical correction owner validates it; - target is the canonical obligation destination; - amount is exact; - compensating/replacement Ledger path exists; - reason is explicit; - Administrator confirms. Do not use this path to: - repair the historical 195-Copper delta; - alter arbitrary Wallets; - reimburse an Administrator; - conceal prior unauthorized movement. --- # Pause, cancellation, closeout, and return Pause blocks new program use but does not undo valid settled outcomes. Cancellation stops new use and begins closeout. Closeout calculates: ```text released amount - valid used amount - active valid commitments = unused returnable amount ``` Closeout must: 1. validate child obligations; 2. settle earned obligations; 3. cancel unused reservations; 4. release unused escrow; 5. post compensating Aquifer return; 6. update totals; 7. publish result; 8. complete exactly once. Unused value always returns to the canonical Aquifer owner. It never returns to proposer, approver, executor, destination controller, beneficiary, or Administrator. --- # Administrator workbench Extend the existing Aquifer Governance workbench. Preferred sections: ```text Aquifer Overview Proposals Decision Queue Authorizations Release Operations Wardship Programs Quest Releases Offering Releases Event Programs Public-Purpose Programs Public Releases Contributions Policy Diagnostics ``` ## Release Operations Show: - authorizations awaiting execution; - authorization ceiling; - amount already executed; - remaining authorization; - destination; - purpose category; - related-party disclosure; - current available Aquifer; - release preview; - release state; - public record; - Ledger group; - closeout state. Actions: ```text Preview Release Execute Release Pause Program Resume Program Cancel Program Close Program Return Unused Value Retry Failed Release Inspect Ledger ``` Never expose: ```text Send to Wallet Grant Personal Coin Transfer to Admin Adjust Aquifer Balance Delete Release Hide Release ``` ## Diagnostics Show: - classified 195-Copper historical delta; - Rootwater custody liability; - available uncommitted; - authorized unexecuted; - active committed releases; - outflow Ledger groups; - return Ledger groups; - conservation; - failed actions; - stale releases; - oversubscription attempts; - personal-Wallet blocks; - disclosures; - gates. No repair-balance button. --- # Member Aquifer surface Members see: - Aquifer balance; - active public programs; - onboarding campaigns; - executed releases; - purpose; - destination; - amount released; - used; - returned; - status; - closeout; - own contribution history. Members cannot: - inspect private proposals; - execute releases; - inspect other members’ contributions; - view private beneficiary data; - rank contributors. Public onboarding campaigns may expose title, purpose, tier, eligibility, remaining quantity, dates, and acceptance path. Use canonical Wardship acceptance. --- # Gates Add the smallest database-backed development gates required. Suggested gates: ```text development.aquifer.release.preview development.aquifer.release.execute development.aquifer.release.closeout development.aquifer.wardship_release development.aquifer.quest_release development.aquifer.offering_release development.aquifer.event_release development.aquifer.public_purpose_release development.aquifer.correction_release development.aquifer.public_records ``` Every gate requires: - development environment; - dataset generation `V6-DEV-2026-08-03-G01`; - non-public-launch state; - Migration 046; - new release migration; - active constitution; - active authorization; - current owners; - fail-closed unknown state. Global execution gate defaults off until schema, contracts, and focused tests are installed. All twenty-five file-backed gates remain disabled. No external payment gate is enabled. --- # Schema and migration Audit Migration 046 first. Prefer one additive next migration. If Migration 047 remains next, use it; do not assume blindly. Potential objects: - releases; - release actions/idempotency; - Ledger mappings; - amount components; - closeout/returns; - public records; - Wardship campaigns and issuances; - Quest mappings; - Offering pools; - Event programs; - public-purpose programs; - correction mappings; - child-obligation links. Requirements: - integer Copper; - immutable release source; - unique idempotency; - one public record per release; - one terminal closeout; - cumulative release ≤ authorization ceiling; - component totals ≤ release amount; - exact reconciliation; - no request-time DDL; - no duplicate domain tables; - no `_v4` or `_v5` changes; - install/replay proof; - rollback posture. --- # Ledger transaction families Use current canonical vocabulary where available. Potential families: ```text aquifer_release_commit aquifer_wardship_commit aquifer_quest_escrow aquifer_offering_pool aquifer_event_program aquifer_public_purpose_commit aquifer_corrective_release aquifer_release_return aquifer_release_reversal ``` Every group records Aquifer source, release, authorization, proposal, constitution, purpose, destination, disclosure, executing Administrator, dataset, idempotency, and public record. Do not use a generic Wallet-transfer family. --- # Idempotency Suggested keys: ```text aquifer-release-preview:: aquifer-release-execute:: aquifer-release-close:: aquifer-release-return:: aquifer-wardship-issue:: aquifer-quest-commit:: aquifer-offering-commit:: aquifer-event-commit:: aquifer-public-purpose-commit:: aquifer-correction-commit:: ``` Duplicate terminal actions replay. Changed payload under an existing key blocks. One authorization cannot duplicate release value. One closeout cannot return twice. --- # Concurrency Prove at minimum: 1. two executions against one authorization create one release; 2. two partial executions cannot exceed the ceiling; 3. two authorizations cannot oversubscribe the Aquifer; 4. execution versus authorization cancellation yields one path; 5. execution versus governance revision uses one constitution; 6. Wardship issuance race creates one unit; 7. Wardship acceptance race creates one membership activation; 8. Quest release funds escrow once; 9. Offering settlement versus closeout preserves exact value; 10. Event child-use versus closeout preserves exact value; 11. closeout versus cancellation returns once; 12. two closeouts return once; 13. public-record publication creates one record; 14. gate disable versus execution is committed or blocked; 15. Rootwater custody liability cannot be spent; 16. historical delta remains unchanged. Report exact lanes and assertions. --- # Failure injection Inject failures after: 1. release action reservation; 2. release insert; 3. purpose-contract creation; 4. Aquifer Ledger outflow; 5. release/Ledger link; 6. public-record publication; 7. Wardship campaign creation; 8. Wardship issuance; 9. membership activation; 10. Quest escrow funding; 11. Offering pool reservation; 12. Offering settlement; 13. Event child commitment; 14. closeout calculation; 15. return Ledger group; 16. audit before response; 17. gate disable; 18. retained campaign creation; 19. controlled cleanup. Required outcomes: - no duplicate release; - no duplicate Wardship; - no duplicate membership term; - no duplicate Quest escrow; - no duplicate Offering settlement; - no oversubscription; - no personal-Wallet credit; - no lost value; - no orphan purpose contract; - no unlinked Ledger group; - no secret executed release; - no duplicate return; - no false success; - exact recovery. --- # Conservation Aquifer global: ```text opening available Aquifer + valid inflows - purpose-bound release outflows + release returns = current available Aquifer ``` Authorization: ```text authorized ceiling = executed total + cancelled amount + remaining amount ``` Release: ```text release amount = used + active commitments + returned + remaining ``` Wardship campaign: ```text committed = accepted/consumed + active issued unaccepted + returned + remaining ``` Quest: ```text Aquifer Quest release = rewards paid + active escrow + returned unused escrow ``` Offering: ```text Aquifer Offering release = settled use + active reservations + refunded/restored + returned unused pool ``` Event/public purpose: ```text program release = settled use + valid child commitments + returned + remaining ``` Any unexplained variance is critical. Reads do not auto-repair. --- # Privacy and security Prove: - Administrator appointment is server-resolved; - authorization and destination are server-resolved; - no raw Wallet destination; - no personal-Wallet release; - no Administrator-Wallet release; - no unrestricted House/Event/Entity grant; - private proposal details remain private; - executed release becomes public; - beneficiary privacy is preserved; - Wardship eligibility is server-validated; - disclosure is server-computed; - CSRF and same-origin protections; - bounded amounts and quantities; - exact confirmations; - no provider secrets; - no password/session logging; - no hidden release deletion; - no delta mutation. --- # Browser acceptance Use connected browser control when available. Administrator checks: - authorization queue; - preview; - balance impact; - custody exclusion; - disclosure; - execute; - public record; - Wardship campaign; - issuance and acceptance; - Quest release; - Offering release; - Event program; - pause; - close; - return unused; - Ledger inspection; - conservation; - Wallet destination blocks; - responsive and accessible operation. Member checks: - public release history; - active onboarding campaign; - Wardship acceptance; - use/return accounting; - own contribution; - private proposal hidden; - no execution controls; - no leaderboard; - responsive and accessible operation. When browser control is unavailable, create an open `V6_CONTROLLED_AQUIFER_RELEASE_BROWSER_ACCEPTANCE.md` and do not claim physical evidence. --- # Controlled proof Prove: ## Common engine - preview; - execute; - partial execute; - authorization ceiling; - balance revalidation; - disclosure; - public record; - duplicate replay; - payload conflict; - Wallet blocks; - custody exclusion; - delta preservation. ## Onboarding campaign - proposal; - authorization; - execution; - canonical campaign; - at least three Wardships; - at least two accepted; - membership activation; - one unused/cancelled unit; - closeout; - unused return; - public record; - no beneficiary Wallet credit; - no external payment. ## Individual Wardship - issue; - accept; - duplicate block; - unused return. ## House Wardship - leader acceptance; - standing activation; - no governance rights; - unused return. ## Quest - exact escrow; - participant reward; - no double payout; - cancellation; - unused return; - public accounting. ## Offering - approved mode; - reservation; - fulfillment; - settlement; - cancellation; - refund; - unused return; - no premature controller credit. ## Event - bounded program; - child purpose; - usage; - closeout; - unused return; - no generic Wallet grant. ## Public purpose Prove only when a safe bounded contract exists; otherwise report unavailable without failing safe paths. ## Correction Prove only against a controlled valid correction fixture, never the historical delta. ## Closeout Prove full use, partial use, zero use, cancellation, return, duplicate replay, and public final record. Controlled proof residue must be zero. Retained operator-play data must be explicitly enumerated. --- # Tests and regressions Add focused safe tests for: - environment fail-closed; - dataset; - schema; - constitution; - authorization; - authorization ceiling; - available balance; - custody exclusion; - delta exclusion; - destination validation; - disclosure; - public records; - personal-Wallet blocks; - Wardship campaigns; - individual and House Wardships; - Quest escrow; - Offering pools; - Event programs; - public-purpose safe path or explicit block; - correction safe path; - closeout; - return; - read safety; - idempotency; - concurrency; - failure recovery; - conservation; - privacy; - no external payment; - no Harvest; - no broad Drift; - no Convergence; - no `_v4`/`_v5` changes; - zero residue. Run exact counts for: - Controlled Aquifer Release focused suite; - controlled lifecycle proof; - concurrency proof; - failure-injection proof; - Aquifer Governance; - Wallet Capacity; - Rootwater; - Rain; - Auth and identity; - Membership and standing; - Wardships and House Wardships; - Universal Dex; - Development Economy; - Quest; - Offering; - Event/House authority; - Wallet/Ledger/transfer; - Character Home; - Coin Purse; - Aquifer workbench; - member Aquifer surface; - Laboratory; - documentation; - exact safe inventory; - gate inventory; - residue/manifests/permits/unavailable sources. All current authoritative suites remain green. --- # Documentation Create canonical equivalents of: - `V6_CONTROLLED_AQUIFER_RELEASE_ACTIVATION_CONTRACT.md` - `V6_AQUIFER_RELEASE_LEDGER_AND_CLOSEOUT_CONTRACT.md` - `V6_AQUIFER_ONBOARDING_WARDSHIP_RELEASE_CONTRACT.md` - `V6_AQUIFER_QUEST_RELEASE_CONTRACT.md` - `V6_AQUIFER_OFFERING_RELEASE_CONTRACT.md` - `V6_AQUIFER_EVENT_RELEASE_CONTRACT.md` - `V6_AQUIFER_PUBLIC_PURPOSE_RELEASE_CONTRACT.md` - `V6_AQUIFER_CORRECTIVE_RELEASE_CONTRACT.md` - `V6_AQUIFER_RELEASE_ADMIN_WORKBENCH_CONTRACT.md` - `V6_AQUIFER_PUBLIC_RELEASE_TRANSPARENCY_CONTRACT.md` - `V6_CONTROLLED_AQUIFER_RELEASE_TEST_PLAYBOOK.md` - `V6_CONTROLLED_AQUIFER_RELEASE_ACTIVATION_COMPLETION.md` - browser acceptance document when needed. Update current command brief, reconstruction ledger, rebuild status, contract index, Governance completion, Aquifer Operations, Wallet/Ledger, Wardships, Membership, Quest, Offering, Event, member Aquifer route, Admin workbench, navigation, Console, migrations, gates, tests, Laboratory, documentation manifest, and reset plan. Record explicitly: > Aquifer approval and release are separate. Approval creates governance authority. Release creates purpose-bound Ledger movement. > Executed releases are public even when the proposal was private. > No Aquifer release may credit an unrestricted personal Wallet, including an Administrator Wallet. > Unused value returns to the Aquifer through compensating Ledger history. --- # Stop conditions Stop and report if: - authorization remaining cannot be resolved; - custody liability cannot be excluded; - available Aquifer value cannot be locked; - Wardship funding cannot accept Aquifer sponsorship; - Wardship campaign requires a second membership system; - Quest escrow cannot identify Aquifer sponsorship; - Offering lifecycle cannot hold purpose-bound value before settlement; - Event support requires generic Wallet grants; - public records cannot be immutable; - closeout cannot return value exactly; - Wallet destinations cannot be blocked; - execution cannot be idempotent; - gates cannot fail closed; - cleanup cannot reach zero; - official tests cannot return green; - implementation would repair the historical delta; - implementation would alter `_v4` or `_v5`. Report exact conflict, owner, smallest required decision, unchanged value, completed safe paths, and unavailable paths. --- # Required completion handoff Return a numbered handoff covering: 1. status; 2. summary; 3. migration; 4. release owner; 5. policy owner; 6. Ledger owner; 7. closeout owner; 8. purpose adapters; 9. environment and dataset; 10. gates; 11. constitution; 12. Aquifer balance; 13. custody liability; 14. available uncommitted; 15. historical delta; 16. authorization validation; 17. ceiling and partial execution; 18. balance locking; 19. release and public records; 20. privacy handling; 21. disclosure; 22. Wallet blocks; 23. onboarding campaign; 24. campaign quantity; 25. Wardships issued/accepted; 26. membership activation; 27. campaign closeout and return; 28. individual Wardship; 29. House Wardship; 30. Quest release and return; 31. Offering release and return; 32. Event program; 33. public-purpose path; 34. corrective path; 35. pause/cancel/closeout; 36. compensating return; 37. member surface; 38. Admin workbench; 39. Ledger families; 40. audit and security; 41. idempotency; 42. concurrency; 43. failure injection; 44. conservation; 45. focused and controlled proofs; 46. regressions; 47. Laboratory and documentation; 48. exact inventory and gates; 49. residue; 50. external payment, cash, Harvest, broad Drift, Convergence, scheduling, and production state; 51. browser evidence; 52. reset plan; 53. `_v4`/`_v5` changes; 54. unavailable paths; 55. recommended next goal; 56. goal usage. --- # Recommended following goal After Controlled Aquifer Release Activation, the default next priority is: ```text V6 Broad Drift Constitution and Development Activation ``` That goal should define broad inactivity or saturation-related Drift beyond the Wallet-cap excess circulation already active. Harvest remains separate. Do not fold broad Drift or Harvest into this Aquifer release goal.