# W/ Founders: Launch Friday

## Your First Transaction Is an Architecture Event

> Leave with a reversible payment-boundary decision and a first-transaction operating runway—not a badge, a launch blessing, or a shortcut to a validation answer.

## Authority and safety boundary

W/ Founders is independent practitioner education using a fictional company and fictional facts. It is not PCI SSC guidance, not an assessment, not a compliance result, not an SAQ-selection or eligibility decision, not legal or investment advice, not launch approval, not provider certification or endorsement, and not direction from a compliance-accepting entity. It does not authorize testing. Never enter account data, credentials, provider secrets, client evidence, restricted architecture, customer information, investor information, or identifying startup facts.

# Fictional case — Launch Friday at Signal Cart

Signal Cart is a fictional pre-revenue software company preparing to accept its first subscription payment. The application uses provider-hosted payment fields inside a company-controlled checkout page. A public callback updates subscription state. Two founders have production access. No customer transaction has completed, but the payment path is deployed and can be enabled with one configuration change.

**Pressure:** At 09:00 Friday, the board asks whether the team can launch at 17:00. The evidence packet contains a provider badge, a pitch deck diagram, a staging test, and an incomplete responsibility spreadsheet.

## Case facts

- **FACT-01 / PRESENT** — The company-controlled checkout route and production DNS are live.
- **FACT-02 / PRESENT** — Provider-hosted fields are embedded in the checkout page; the provider receives entered payment data directly.
- **FACT-03 / PRESENT** — The checkout page, script policy, deployment pipeline, and production configuration remain company-controlled.
- **FACT-04 / PRESENT** — A public callback hostname terminates at a company-managed gateway and invokes company application code.
- **FACT-05 / PRESENT** — Two founders hold production administrator roles; one role can change checkout configuration and callback secrets.
- **FACT-06 / PRODUCTION-CAPABLE** — A feature flag can expose checkout to customers without a new deployment.
- **FACT-07 / PRODUCTION-CAPABLE** — Live provider credentials and callback configuration are present in the production environment.
- **FACT-08 / OBSERVED** — Only staging transaction behavior has been exercised end to end.
- **FACT-09 / DOCUMENTED** — The provider assurance packet names a hosted-field service, but the customer responsibility row is incomplete for script and callback operation.
- **FACT-10 / ASSERTED** — The founders assert that PCI DSS begins after the first successful customer payment.
- **FACT-11 / UNKNOWN** — The current external scan and penetration-test populations do not identify the callback termination.
- **FACT-12 / PROPOSED** — Support wants a session-replay script added to the checkout shell before launch to diagnose abandonment.

# 45-minute run of show

1. **5 min · Name the decision** — Write the exact decision requested, the deadline, who can make it, and what the room cannot conclude.
2. **7 min · Separate capability states** — Classify each payment-relevant capability as proposed, present, production-capable, or effective. Preserve disagreements.
3. **8 min · Trace two paths** — Map where payment data moves and what identities, code, public endpoints, providers, and deployment systems can influence its security.
4. **8 min · Assign retained work** — Separate provider performance from customer configuration, operation, evidence, testing, change, incident, and reporting responsibilities.
5. **7 min · Build the evidence runway** — Name what must exist before launch, at first transaction, after each occurrence, and only after an operating period.
6. **10 min · Inject change and decide** — Introduce the session-replay request, reopen affected facts and claims, then record one bounded decision with conditions, owners, limitations, and triggers.

# Five working records

## FOUNDERS-REC-01 · Payment Capability State Ledger

Keep proposed, present, production-capable, and effective behavior from collapsing into one launch narrative.

| Capability | Current State | Activation Event | Owner | Evidence | Open Fact | Reopening Trigger |
| --- | --- | --- | --- | --- | --- | --- |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |

## FOUNDERS-REC-02 · Pre-Launch Boundary Map

Join account-data movement to the identities, code, endpoints, providers, and deployment paths that can influence it.

| Subject | Relationship | Data Or Influence | Owner | Provider Dependency | Evidence | Uncertainty |
| --- | --- | --- | --- | --- | --- | --- |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |

## FOUNDERS-REC-03 · Provider Responsibility Brief

Turn provider reliance into exact service, activity, configuration, evidence, and retained-customer-duty statements.

| Service | Provider Activity | Customer Activity | Assurance Source | Implementation Evidence | Conflict | Reverification Event |
| --- | --- | --- | --- | --- | --- | --- |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |

## FOUNDERS-REC-04 · First-Transaction Evidence Runway

Separate pre-launch proof from first-occurrence evidence and evidence that requires operating time.

| Evidence Event | Before Launch | First Transaction | Recurring Occurrence | Period Required | Owner | Retention |
| --- | --- | --- | --- | --- | --- | --- |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |

## FOUNDERS-REC-05 · Launch Decision and Reopening Record

Preserve the decision the named owner actually made without turning the room into approval, assessment, or acceptance authority.

| Decision Requested | Current Facts | Decision | Conditions | Owner | Limitations | Reopening Triggers |
| --- | --- | --- | --- | --- | --- | --- |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |

# Change injection — The Thursday Replay Request

**Trigger:** Support asks engineering to add a third-party session-replay script to the company-controlled checkout shell before launch so founders can diagnose abandonment.

**Anti-shortcut:** Do not conclude that the script is automatically in scope, out of scope, compliant, or prohibited. Establish what it can observe or influence, where it loads, how it is governed, and which claims no longer survive unchanged.

**Stopping question:** Which exact boundary statement can remain true after this script is enabled, and what evidence supports it?

# Bounded decision states

- **Proceed with bounded conditions** — The accountable business owner can proceed only with named conditions, owners, timing, and reopening triggers; this is not a compliance result.
- **Hold for facts** — A material factual uncertainty prevents a responsible business decision until it is resolved.
- **Change the boundary** — The current architecture creates obligations or uncertainty the team elects to redesign before launch.
- **Escalate validation direction** — The team needs direction from its compliance-accepting entity and qualified professional; the room cannot supply it.

# Next gate

Scott Norton records an exact-digest practitioner disposition, then one real founder, incubator, or accelerator partner runs the fictional 45-minute room. Preserve the first fracture, smallest repair, and second-reader retest before commissioning slides, a campaign, credentials, or a broader startup program.