INPUT MAPPING FOR THE UPGRADED G16 WORKFLOW Use closure-register-template.csv as closure-register.csv and request-ledger-template.csv as request-ledger.csv. Complete policy-template.txt and provide it as policy.txt. Keep all three in the same approved synthetic input packet when using the optional AI setup-review prompt. closure-register.csv: matter_alias, contact_alias, location_alias, closed_at, closure_verified, email_permission, opted_out, privacy_hold, reopened, reviewer, policy_version, approval, reviewer_decision, decision_at, approval_valid_until request-ledger.csv: contact_alias, location_alias, request_id, state, requested_at, reserved_at, send_evidence_ref; policy.txt: launch cohort, timezone, cooldown_days, approved closure rule, privacy criteria, approved template, verified review URL These are editorial input schemas, not Lawmatics export headers. Verify each actual field, its meaning, current-state checks and recipient mapping before any separately authorized setup. A recorded task completion or tag alone is not approval. The workflow guide defines the current approval and recorded reviewer-decision gates. The earlier services.csv, request-log.csv, Eligibility/ApprovedPolicy/VerifiedLink/Scope files and their synthetic outputs are preserved under legacy/. They cannot be renamed into the new closure/ledger contract: matter/contact/location pairing, permission freshness, review state, contact-level reservations and send evidence must be established separately. Proposed field names and ledger schemas are editorial, not native export headers. Lawmatics documents a once-per-target automation limit, but separate matters and manual reruns require additional contact-level deduplication. Atomic cross-matter locking is not verified. Never copy a positive/neutral/negative review-routing template: the same genuine review opportunity must not depend on sentiment or case outcome. Live entitlements, available custom-field conditions, exact recipient mapping, unsubscribe behavior, cross-matter dedup and delivery-window rechecks require synthetic testing. If timely pre-send checks or reliable reservation cannot be implemented, automate the task only and keep the email send manual. Verify the live account can require a current approval=true field and recorded reviewer decision at dispatch; otherwise use the manual-send fallback. No real client data, official form, importable automation or completed execution test is supplied. The test plan describes expected observations; it is not evidence that Lawmatics enforces those controls.