# W/ Practice Rooms ## Eight Rooms. Eight Decisions. No Generic PCI Lecture. > Enter through the decision your audience actually owns, then reconnect that decision to the payment story, authority, evidence, and change that make it defensible. Convert eight governed Learning Pathways into bounded, audience-specific practice briefs without duplicating the technical library or pretending that a commissioning room is already a validated curriculum. ## Operating model 1. **W/? Enter** — Name the consequential question this audience already owns. 2. **W/ Map** — Place that question inside the complete payment and security-influence story. 3. **W/! Challenge** — Expose the unsupported assumption, missing owner, or evidence limit. 4. **W/→ Decide** — Record the bounded decision, accountable owner, and downstream consequence. 5. **W/✓ Preserve** — Keep the artifact and reopening trigger another person can use later. ## Authority and safety boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. # W/ Workforce — The Transferable-Skills Interview **Room:** ROOM-01 · **Portfolio stage:** Next **Audience:** Career-transition programs, workforce boards, veterans, displaced technology workers, and career counselors > A job title is not a career pathway. Show the work product. ## Consequential question How can prior experience become credible payment-security work without pretending it creates authority the learner has not earned? ## Fictional scenario A fictional workforce cohort includes a network technician, retail operations manager, veteran logistics specialist, junior developer, and internal auditor. **Pressure:** Each learner has ninety days to produce one safe portfolio artifact and explain which role families it supports. ## Five working artifacts - [ ] Prior-experience-to-capability map - [ ] Fictional payment-journey narrative - [ ] Claim-and-evidence portfolio record - [ ] Authority and ethics boundary - [ ] Ninety-day practice runway # Four practice moves ## 1. Translate **Prompt:** Convert prior work into observable capabilities without inflating titles. **Output:** Capability map ## 2. Build **Prompt:** Choose one fictional project that exposes architecture, operations, evidence, or assurance reasoning. **Output:** Project brief ## 3. Explain **Prompt:** State what the artifact proves, what it does not prove, and who could review it. **Output:** Bounded portfolio claim ## 4. Route **Prompt:** Connect the demonstrated capabilities to more than one realistic role family. **Output:** Role-branching map ## Bounded decision output A ninety-day, artifact-first career pathway with no employment or qualification promise. ## Pilot format One counselor and three learners complete the same fictional case, then compare where prior experience changed the chosen artifact—not the authority boundary. ## Stop rule Stop if the exercise starts scoring employability, certifying competence, collecting sensitive career data, or treating PCI assessor status as an entry-level outcome. ## Reviewed reading route - WACK-CONTENT-0163 - WACK-CONTENT-0162 - WACK-CONTENT-0154 - WACK-CONTENT-0157 - WACK-CONTENT-0161 ## Program boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. --- # W/ Founders — Launch Friday **Room:** ROOM-02 · **Portfolio stage:** Next **Audience:** Founders, incubators, accelerators, early product teams, and technical co-founders > Your first transaction is an architecture event, not merely a revenue event. ## Consequential question Which payment capabilities become present, production-capable, or effective before the first dollar arrives? ## Fictional scenario A fictional startup embeds provider-hosted payment fields, receives a public webhook, grants two founders production access, and has not yet processed a transaction. **Pressure:** The board wants launch approval Friday; the team has a provider badge, a pitch deck, and incomplete operating records. ## Five working artifacts - [ ] Payment-capability state ledger - [ ] Pre-launch boundary map - [ ] Provider responsibility brief - [ ] First-transaction evidence runway - [ ] Launch reopening triggers # Four practice moves ## 1. Separate **Prompt:** Distinguish proposed, present, production-capable, and effective behavior. **Output:** Capability-state table ## 2. Trace **Prompt:** Map account-data and security-influence paths through page, identity, deployment, callback, and provider. **Output:** Dual-path map ## 3. Commit **Prompt:** Name the operating obligations the architecture creates before revenue. **Output:** Owner runway ## 4. Gate **Prompt:** State the facts required for a bounded launch decision and what would reopen it. **Output:** Launch decision record ## Bounded decision output A reversible payment-boundary decision and first-transaction operating runway. ## Pilot format A 45-minute founder boundary session using one fictional architecture and one material late-stage change. ## Stop rule Stop if the room becomes launch approval, legal advice, investment diligence, an SAQ-selection engine, or a provider endorsement. ## Reviewed reading route - WACK-CONTENT-0138 - WACK-CONTENT-0140 - WACK-CONTENT-0139 - WACK-CONTENT-0105 - WACK-CONTENT-0097 ## Program boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. --- # W/ Finance — The Missing Settlement **Room:** ROOM-03 · **Portfolio stage:** Next **Audience:** Finance teams, accounting students, controllership, internal audit, reconciliation owners, and revenue operations > The payment story does not end when authorization succeeds. ## Consequential question Can finance and security reconstruct the same transaction exception from authorization through settlement, ledger, dispute, and evidence? ## Fictional scenario A fictional authorized payment has a provider reference, no expected settlement line, a manual refund note, and two dashboards that disagree. **Pressure:** Month-end closes tomorrow while security and finance use different identifiers and different definitions of complete. ## Five working artifacts - [ ] Transaction-to-ledger lineage - [ ] Five-state reconciliation record - [ ] Exception ownership map - [ ] Claims ledger entry - [ ] Reopening and retention rule # Four practice moves ## 1. Join **Prompt:** Link authorization, token or reference, settlement, ledger, refund, dispute, and evidence identifiers. **Output:** Lineage record ## 2. Reconcile **Prompt:** Separate expected, observed, documented, asserted, and validated states. **Output:** State comparison ## 3. Own **Prompt:** Assign the exception, decision, evidence, and correction to named roles. **Output:** Responsibility handoff ## 4. Close **Prompt:** Record the bounded conclusion, limitation, retention, and reopening event. **Output:** Claim disposition ## Bounded decision output One cross-functional exception record that finance and security can independently reconstruct. ## Pilot format A finance reader and security reader work the same fictional exception separately, then reconcile only from retained artifacts. ## Stop rule Stop if the room produces an accounting opinion, audit conclusion, financial advice, or uses live transaction or customer data. ## Reviewed reading route - WACK-CONTENT-0107 - WACK-CONTENT-0129 - WACK-CONTENT-0095 - WACK-CONTENT-0104 - WACK-CONTENT-0142 ## Program boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. --- # W/ Nonprofit — Giving Week **Room:** ROOM-04 · **Portfolio stage:** Later **Audience:** Nonprofits, associations, fundraising teams, finance staff, event volunteers, and technology partners > A donation campaign is a payment estate—even when everyone helping is a volunteer. ## Consequential question Where do web, event, telephone, recurring-gift, refund, and volunteer-supported payment journeys intersect? ## Fictional scenario A fictional nonprofit uses a hosted donation page, rented event readers, telephone pledges, recurring gifts, and a volunteer-managed spreadsheet. **Pressure:** The annual campaign begins in two weeks, the provider documents cover only some services, and ownership changes after the event. ## Five working artifacts - [ ] Donation-journey inventory - [ ] Seasonal device and volunteer map - [ ] Provider-service responsibility card - [ ] Access exit checklist - [ ] Campaign closeout evidence index # Four practice moves ## 1. Inventory **Prompt:** Name every way a donor can pay, including alternate and support paths. **Output:** Journey register ## 2. Separate **Prompt:** Distinguish provider operation from nonprofit configuration, people, devices, and records. **Output:** Responsibility card ## 3. Time-box **Prompt:** Map temporary devices, accounts, volunteers, exceptions, and their required exits. **Output:** Seasonal control plan ## 4. Close **Prompt:** Preserve evidence, remove access, return devices, and record what remains recurring. **Output:** Campaign closeout ## Bounded decision output A complete seasonal donation story with explicit post-campaign ownership. ## Pilot format A nonprofit operator and provider reviewer validate the fictional journeys and identify the first oversimplified responsibility statement. ## Stop rule Stop if volunteer status is treated as a control, donor data is requested, or the room becomes charitable-law advice or SAQ selection. ## Reviewed reading route - WACK-CONTENT-0144 - WACK-CONTENT-0145 - WACK-CONTENT-0151 - WACK-CONTENT-0150 - WACK-CONTENT-0152 ## Program boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. --- # W/ Public Service — One City, Seven Counters **Room:** ROOM-05 · **Portfolio stage:** Later **Audience:** Municipalities, libraries, public institutions, shared-service teams, procurement, and departmental payment owners > Decentralized service does not erase centralized accountability. ## Consequential question Who owns a public payment estate spread across counters, portals, departments, contractors, and shared infrastructure? ## Fictional scenario A fictional city accepts payments for permits, recreation, utilities, library fines, parking, events, and public records through several departments and providers. **Pressure:** Procurement lists contracts; IT lists systems; departments list services. No list describes the complete payment estate. ## Five working artifacts - [ ] Public-service payment estate map - [ ] Department-to-shared-service relationship ledger - [ ] Procurement-to-operation handoff - [ ] Public-presence register - [ ] Decision-authority map # Four practice moves ## 1. Federate **Prompt:** Join departmental payment journeys without erasing local ownership. **Output:** Estate map ## 2. Relate **Prompt:** Map shared identity, network, hosting, provider, support, and procurement relationships. **Output:** Relationship ledger ## 3. Handoff **Prompt:** Translate contract promises into operational owners, evidence, and renewal triggers. **Output:** Responsibility handoff ## 4. Escalate **Prompt:** Name which body can decide, accept, fund, or reopen each unresolved issue. **Output:** Authority route ## Bounded decision output A federated payment-estate record that preserves departmental and shared-service accountability. ## Pilot format A public-sector practitioner challenges the fictional procurement, records, shared-service, and authority assumptions before facilitation is commissioned. ## Stop rule Stop if the room becomes procurement advice, records-retention advice, government policy, or a description of a real public system. ## Reviewed reading route - WACK-CONTENT-0104 - WACK-CONTENT-0116 - WACK-CONTENT-0132 - WACK-CONTENT-0022 - WACK-CONTENT-0093 ## Program boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. --- # W/ Healthcare Payments — The Patient Balance **Room:** ROOM-06 · **Portfolio stage:** Later **Audience:** Healthcare payments, revenue cycle, patient experience, security, privacy, clinical operations, and provider management > Shared systems do not make PCI DSS and healthcare obligations interchangeable. ## Consequential question How can one patient-payment journey preserve separate account-data, privacy, clinical, support, and provider-responsibility views? ## Fictional scenario A fictional patient pays through a portal, calls support after a failure, and receives a refund while shared identity and contact-center systems support the workflow. **Pressure:** Teams want one crosswalk to answer every question, but the authorities, data, owners, and evidence differ. ## Five working artifacts - [ ] Multi-authority journey map - [ ] Account-data and security-influence graph - [ ] Identity and support-plane map - [ ] Provider seam record - [ ] Authority-specific claim ledger # Four practice moves ## 1. Trace **Prompt:** Narrate normal, failure, support, refund, and administrative paths. **Output:** Complete patient-payment story ## 2. Separate **Prompt:** Keep PCI DSS, privacy, clinical, contractual, and operational questions in their own authority lanes. **Output:** Authority overlay ## 3. Connect **Prompt:** Show shared identities, devices, services, providers, and support capabilities without claiming equivalence. **Output:** Relationship graph ## 4. Bound **Prompt:** State what each evidence set supports and which reviewer can conclude what. **Output:** Claim boundary ## Bounded decision output A dual-boundary case that connects shared facts while preserving distinct authorities. ## Pilot format Healthcare security and privacy reviewers independently mark authority overreach in the same fictional case, then reconcile the boundaries. ## Stop rule Stop if patient data enters the room or the exercise implies HIPAA conclusions, framework equivalence, healthcare advice, or an assessment result. ## Reviewed reading route - WACK-CONTENT-0120 - WACK-CONTENT-0116 - WACK-CONTENT-0122 - WACK-CONTENT-0130 - WACK-CONTENT-0158 ## Program boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. --- # W/ ISV Academy — The Compliant Product Claim **Room:** ROOM-07 · **Portfolio stage:** Later **Audience:** Independent software vendors, SaaS product teams, implementation partners, sales engineering, and customer success > A product claim is not a customer responsibility model. ## Consequential question Can product and customer teams derive the same bounded PCI responsibility statement from one deployment? ## Fictional scenario A fictional ISV markets a PCI-compliant payment module deployed into customer cloud accounts with optional support, webhooks, identity integration, and managed updates. **Pressure:** Sales, product, implementation, and the customer each mean something different by ‘handled by the platform.’ ## Five working artifacts - [ ] Claim decomposition record - [ ] Deployment-pattern matrix - [ ] Product/customer responsibility model - [ ] Evidence handoff contract - [ ] Change-notification covenant # Four practice moves ## 1. Decompose **Prompt:** Separate product capability, hosted service, deployment, configuration, assurance, and customer outcome claims. **Output:** Claim stack ## 2. Instantiate **Prompt:** Apply the claim to an exact service, mode, region, feature set, and customer deployment. **Output:** Deployment profile ## 3. Assign **Prompt:** Map provider, ISV, implementer, and customer activities with evidence and retained duties. **Output:** Responsibility model ## 4. Handoff **Prompt:** Specify what the customer receives, must configure, must prove, and must revisit after change. **Output:** Customer assurance packet ## Bounded decision output One deployment-specific customer responsibility statement that survives product, implementation, and customer review. ## Pilot format One product team and one customer implementation team independently derive the statement from the fictional deployment and compare omissions. ## Stop rule Stop if the room becomes product certification, vendor endorsement, a customer compliance result, or marketing-copy optimization. ## Reviewed reading route - WACK-CONTENT-0124 - WACK-CONTENT-0099 - WACK-CONTENT-0128 - WACK-CONTENT-0158 - WACK-CONTENT-0100 ## Program boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. --- # W/ Boardroom — The Green Quarter **Room:** ROOM-08 · **Portfolio stage:** Later **Audience:** Executives, boards, investors, accountable business owners, and senior risk leaders > Green is a color. What decision does it support? ## Consequential question Can leadership see the operating dependencies, evidence limits, missed work, and decision requests beneath the status? ## Fictional scenario A fictional board packet reports PCI compliance as green while one quarterly scan was missed, a provider matrix conflicts with architecture, and a remediation will finish next quarter. **Pressure:** Management wants a twenty-minute briefing that is candid, decision-ready, and free of requirement-number theater. ## Five working artifacts - [ ] One-journey executive map - [ ] Claims-and-limitations ledger - [ ] Missed-occurrence decision record - [ ] Three accountable decision requests - [ ] Reopening trigger card # Four practice moves ## 1. Translate **Prompt:** Replace framework status with the business capability, dependency, and consequence at issue. **Output:** Executive payment story ## 2. Disclose **Prompt:** Separate current evidence, future remediation, uncertainty, and acceptance-boundary direction. **Output:** Truth table ## 3. Request **Prompt:** Ask leadership for a named decision, owner, resources, and due state—not generic awareness. **Output:** Decision slate ## 4. Reopen **Prompt:** Define which change, missed occurrence, contradiction, or evidence limit returns the matter to leadership. **Output:** Governance trigger ## Bounded decision output A twenty-minute claims-and-consequences briefing with three explicit decisions and no false assurance. ## Pilot format An executive reader names the decision, owner, evidence limit, and reopening trigger before PCI terminology is introduced. ## Stop rule Stop if the room produces board assurance, investment advice, risk acceptance, or a compliance conclusion on leadership's behalf. ## Reviewed reading route - WACK-CONTENT-0019 - WACK-CONTENT-0095 - WACK-CONTENT-0115 - WACK-CONTENT-0128 - WACK-CONTENT-0142 ## Program boundary W/ Practice Rooms is practitioner-developed commissioning material. It is not PCI SSC guidance, not an assessment, not a compliance result, not an accredited curriculum, not professional certification, and not legal, financial, healthcare, public-sector, employment, or product-validation advice. Every room uses fictional facts and requires its named pilot before expansion. # Next gate Select one room because a real partner exists, not because its label is attractive. Run the smallest fictional exercise, preserve the first fracture, repair the shared artifact, and retest before commissioning a full program.