METHOD IN PRACTICE INDEPENDENT PORTFOLIO EXERCISE

Roadmapping as a
Decision Interface

Show the decision. Reveal the reasoning when it matters.

An independent American Express Membership scenario showing how I communicate an executive roadmap: four proposed milestones, eight candidate bets, and deeper shaping available on demand.

Start with the customer struggle, not a feature. Group bets by what they might unlock. Fix appetite (time × team); adjust scope to fit. No candidate bet exceeds six weeks.

Independent portfolio example. I have not worked for or been commissioned by American Express. This is not an Amex strategy, internal document, or endorsed presentation. All bets, priorities, staffing, budgets, TEST/HOLD designations, and assumed efficiencies are illustrative—not company decisions or measured outcomes.

HOW TO READ THISAn executive overview, with the detail available on demand
01 · DIRECTIONSee the sequenceWhy these problems, in this order?
02 · INVESTMENTChoose a betWhat is it worth learning or solving?
03 · JUDGMENTInspect the caseCurrent struggle, alternatives and success check
04 · SHAPINGGo one level deeperScope, risks and the decisions still open
Model notes Appetite + candidate shapes
Appetite = fixed time × talent budget.

Appetite is a judgment about how much team time the problem is worth, not a delivery estimate. Fix time and team, then adjust scope to fit. The total on this roadmap includes only bets with a draft appetite; unassigned work is not silently budgeted.

Stop rule: clear the quality floor with the least human review. As the cap approaches, cut optional scope, verify what matters, preserve state, and land. At the cap, stop. More capacity is a new bet.

Candidate shapes, not specifications.

The yellow candidate shape is one raw mechanism for illustrating the struggle. It is not a selected design, product commitment, or promise of effectiveness. Keep the situation and desired outcome distinct from the mechanism. No observed outcomes are claimed here.

What to pursue, in what order, and why.

Select a milestone to inspect the candidate bets. Open any bet for its problem, proposed response, trade-offs, evidence and delivery boundaries. The deeper Automatic Offers shaping example is optional.

4 proposed milestones · 51 illustrative person-wks across sized bets
1

Milestone 1 · Realize & Verify Membership Value

Make promised value usable and reliably delivered.

Why here: Start with current benefits, not new autonomy. Test purchase-time incrementality and whether failed benefit outcomes justify intervention.

2 test9 person-wks draft1 appetite TBD
1.1 · Automatic OffersPurchase decision • in-context Membership valueTEST · evidence bet Shaping & v1 ↗Draft appetite3 wks × 39 person-wks Show Frame + Candidate ShapeHide Frame + Candidate Shape
Struggling moment · x

When I am about to pay and an Amex Offer may apply, I cannot tell in time which benefit is eligible, which Card to use, or whether activation is required.

Current approach · f₀(x)

Check Offers beforehand, interpret merchant and Card terms, add the right Offer, then remember it at checkout—or miss the step.

Current result · y₀

I either spend effort hunting for discounts or miss value that may already be available to me.

Candidate shape · fᵢ(x)

A permissioned Amex assistant surfaces the applicable Offer at the point of purchase and handles allowed activation, otherwise requesting explicit action. It never treats every eligible discount as economically incremental.

Desired outcome · y

Relevant, legitimate Membership value is realized at the moment of choice without requiring a separate coupon-management task.

Success check

Against current Amex and CardPointers workflows, did net incremental merchant-valued purchases and Card Member value rise after subsidy, cannibalization and service costs?

Other candidate options: Amex app, permitted browser integration, checkout, and optional location-aware surfacing. A customer-invoked personal AI agent is another potential approved surface for Offer discovery or eligibility checks; enrollment remains governed by program terms and explicit permission. Local Membership Layer is merged here as a possible context—not another funded bet.

M · What must be true

  • Amex can determine Offer, merchant and Card eligibility, terms and activation state.
  • At least one approved surface can detect purchase context with consent.
  • Merchant campaign rules and baseline redemption economics are accessible for a controlled test.
  • Consent is revocable and any enrollment/action is auditable.

R · What any better way must do

Timely valueEligible and compliantBounded consentMinimal effortVerified incremental economics
Business-value caseTEST

Medium–high, conditional · strategic potential, not forecast revenue

How Amex might benefit

Incremental merchant-campaign contribution, realized customer value and Card preference—not redemption count alone.

Business result to measure

Incremental contribution per exposed eligible purchase, net of merchant incentives, baseline redemptions, agent and servicing cost.

What might break this bet

Most purchases would happen anyway; subsidies rise; third-party tools already solve the pain.

Next evidence / decision gate

Run consented purchase-context holdout against current Amex / CardPointers-like baseline. Stop if only activation/redemption volume grows.

Research trail:E001, E002, E003, E004, E005
Execution budgetIllustrative conversion at 40 hrs/person-week, 2× agent production and 25% review; not an approved execution cap.
9 person-wks
Human-equivalent capacity360 hrs
Machine cap @ 2×180 agent-hrs
Human review @ 25%90 hrs
Quality floorEligibility and activation rules are respected; the Card Member controls permission; relevant value is displayed correctly at purchase time; valid use can be verified.
1.2 · Benefit Outcome AssuranceAfter purchase • credits, benefits, exceptions & agent handoffsTEST · evidence bet Appetite Not assigned Show Frame + Candidate ShapeHide Frame + Candidate Shape
Struggling moment · x

After I use a benefit I believe applies, the promised credit, access or protection does not appear—or the transaction is classified in a way that seems to disqualify it.

Current approach · f₀(x)

Recheck eligibility terms, find the transaction, contact support, supply evidence and follow up until someone explains or resolves the discrepancy.

Current result · y₀

I spend time proving what I expected Membership to deliver and may never learn whether the benefit was valid, delayed or truly denied.

Candidate shape · fᵢ(x)

An authorized Amex assistant checks benefit terms and transaction context, explains the discrepancy, assembles a case and routes eligible exceptions for human-reviewed resolution. As an optional approved pathway, a Card Member’s personal agent could request the authoritative explanation, initiate a scoped case handoff and receive verified status without making the Member repeat the issue.

Desired outcome · y

Eligible benefits arrive reliably; when something fails, I get an accurate explanation and a justified remedy without repeatedly rebuilding the case.

Success check

Did valid unresolved benefits, repeated contacts and time-to-correct-resolution decrease without granting ineligible credits or creating excess cost? For an external-agent handoff, did repeated effort and net cost also fall versus current Amex servicing?

Other candidate options: Proactive credit-status tracking, intelligible benefit eligibility explanations, case evidence packaging, and controlled servicing escalation. External-agent access is a candidate delivery surface, not a separately funded bet.

M · What must be true

  • Authoritative transaction, benefit and offer rules can be joined for an eligible case.
  • Existing service/dispute processes can surface a reason and permitted remedy.
  • An agent cannot adjudicate insurance coverage or override policy without authority.
  • Case outcomes and handling costs can be measured against a baseline.
  • Any external-agent handoff requires an approved host surface, verified Card Member identity, scoped and revocable authority, secure source-of-truth access, traceable case status and escalation. ACE commerce capabilities alone do not establish servicing rights.

R · What any better way must do

Correct eligibilityExplainable decisionsTimely case progressRecoverableHuman-approved exceptionsSafe delegated handoff
Business-value caseTEST

Potentially high; not yet sized · strategic potential, not forecast revenue

How Amex might benefit

Lower repeat-contact and handling costs, increased realized value, and fewer frustrating Membership failures that may harm retention.

Business result to measure

Valid benefit resolution, avoidable contacts and net service cost per eligible case. For an external-agent pathway, measure added handoff completion and repeated effort against existing service; causal retention impact remains unmeasured.

What might break this bet

Most complaints are valid ineligibility, already resolved efficiently, or require legally constrained adjudication. External-agent invocation, account access or servicing rights may not be approved.

Next evidence / decision gate

Audit declined/missing-benefit cases and shadow-test eligibility explanation + case packaging. Test one approved external-agent handoff against current support, checking demand, invocation rights, identity, consent, case status and resolution quality. Assign appetite only after the service gap and quality floor are evidenced.

Research trail:E001, E015, E008, E017, E021
2

Milestone 2 · Make Better, Verifiable Choices

Use Membership only when it can change a real decision.

Why here: Compare feasible dining access and total trip economics with credible current/generic alternatives. Reject manufactured Membership advantages.

2 test30 person-wks draft
2.1 · Verified Dining AccessTime-specific reservation • feasible Membership advantageTEST · evidence bet Draft appetite4 wks × 312 person-wks Show Frame + Candidate ShapeHide Frame + Candidate Shape
Struggling moment · x

When I need a table for a specific occasion and date, the available reservations do not fit my constraints, and I cannot tell whether an Amex access benefit actually changes what I can book.

Current approach · f₀(x)

Search Resy and other providers, change times or locations, check eligibility separately and compare access with ordinary availability.

Current result · y₀

I may settle for a poorer time or venue despite Membership access—or waste time pursuing tables that are not really available.

Candidate shape · fᵢ(x)

Within an approved Resy / Amex pathway, compare live, actually reservable tables for a specific brief against a generic/current search, explain eligible access and recommend feasible alternatives.

Desired outcome · y

I see a genuinely better feasible restaurant choice when Membership makes a real difference—not a prettier list of the same options.

Success check

Does Membership reveal more usable options or change the best feasible choice versus existing Resy experiences, including in-chat booking, and generic search?

Other candidate options: A verified access comparison panel or concierge-assisted search, including invocation by an approved personal agent. Already available in-chat Resy booking is a baseline, not a new benefit. Automated booking beyond approved flows is a separate, permission-gated hypothesis.

M · What must be true

  • Approved provider access returns live, actually reservable options.
  • Membership eligibility and incremental access can be checked reliably.
  • A current/generic baseline and actual booking outcomes can be compared.
  • Rate limits and provider rules prevent unauthorized agent behavior.

R · What any better way must do

Real availabilityIntent-fitDecision-changingHonest explanationProvider-approved
Business-value caseTEST

Medium; conditional · strategic potential, not forecast revenue

How Amex might benefit

Resy engagement, Member preference and partner value if exclusive access changes a real booking outcome.

Business result to measure

Increase in verified feasible options or satisfied bookings causally attributable to Amex access.

What might break this bet

Inventory is identical, eligibility does not help, or existing Resy integration already removes the friction.

Next evidence / decision gate

Blind matched-task experiment using verified date/party availability versus current Resy/Claude, Resy/ChatGPT and generic discovery/booking. Isolate any incremental Membership access from interface convenience.

Research trail:E006, E007, E016, E019, E023
Execution budgetIllustrative conversion at 40 hrs/person-week, 2× agent production and 25% review; not an approved execution cap.
12 person-wks
Human-equivalent capacity480 hrs
Machine cap @ 2×240 agent-hrs
Human review @ 25%120 hrs
Quality floorOnly verified, live, policy-compliant inventory is recommended, and the comparison accurately identifies whether Membership changes a feasible choice.
2.2 · Verified Total Trip ValueBefore booking • compare like-for-like total valueTEST · evidence bet Draft appetite6 wks × 318 person-wks Show Frame + Candidate ShapeHide Frame + Candidate Shape
Struggling moment · x

When the same flight or hotel seems to have different prices, rewards, credits and restrictions across booking channels, I cannot confidently tell which complete option is actually better for my trip.

Current approach · f₀(x)

Compare several booking sites, estimate point values and credits, interpret cancellation and upgrade terms, then reconcile rate differences by hand.

Current result · y₀

I may pay more for a nominal benefit, miss a valid advantage, or book an inferior rate because the comparison is not like-for-like.

Candidate shape · fᵢ(x)

An Amex-aware comparison explains like-for-like total trip cost and eligible value across Amex Travel and direct/other channels, discloses uncertainty and recommends whichever genuinely fits best.

Desired outcome · y

I make a confident, defensible choice based on total value and trip fit—not misleading credit arithmetic or channel preference.

Success check

On identical travel requirements, does verified total-value comparison reduce wrong choices and improve net customer value against ordinary manual/current Amex comparison?

Other candidate options: Value audit at search, independent itinerary comparison, or side-by-side rate-condition explainer. An approved Amex service could also answer a customer-owned travel agent’s specific eligibility, benefits and terms questions. Autonomous booking is not required.

M · What must be true

  • Matched inventory and rate terms can be compared accurately across channels.
  • Membership credits, points, eligibility and restrictions are current and representable.
  • A fair generic/manual comparator and post-booking outcomes can be measured.

R · What any better way must do

Like-for-like pricesReal eligible valueHonest uncertaintyCustomer-best choiceExplainable tradeoffs
Business-value caseTEST

Medium–high, conditional · strategic potential, not forecast revenue

How Amex might benefit

Trust, appropriate Amex Travel participation, realized benefits and durable Card preference if recommendations are demonstrably honest.

Business result to measure

Improvement in verified total customer value and choice quality, net of advisory cost and forgone channel contribution.

What might break this bet

Direct booking frequently wins, Amex pricing dominates the benefit or the data are not comparable.

Next evidence / decision gate

Conduct blinded, timestamped matched-rate comparisons and observe decisions; do not reward only Amex-channel conversion.

Research trail:E001, E009, E020
Execution budgetIllustrative conversion at 40 hrs/person-week, 2× agent production and 25% review; not an approved execution cap.
18 person-wks
Human-equivalent capacity720 hrs
Machine cap @ 2×360 agent-hrs
Human review @ 25%180 hrs
Quality floorOnly genuinely comparable prices/rates are compared; eligibility, points valuation and major restrictions are correct; the system is allowed to recommend a non-Amex channel.
3

Milestone 3 · Resolve & Recover Outcomes

Move from understanding to bounded, reversible help.

Why here: Start with travel disruption diagnosis and case preparation. Preserve delegated booking and itinerary management as conditional options, not funded follow-ons.

1 test2 hold12 person-wks draft
3.1 · Travel Disruption ResolutionIn-trip • immediate, bounded recoveryTEST · evidence bet Draft appetite4 wks × 312 person-wks Show Frame + Candidate ShapeHide Frame + Candidate Shape
Struggling moment · x

When a flight is canceled, a room disappears or another disruption hits during a trip, I urgently need a valid remedy, but the accountable provider, eligible coverage and fastest safe next action are unclear.

Current approach · f₀(x)

Contact several providers, repeat the case, locate receipts, interpret benefit coverage, and pursue claims or alternatives under time pressure.

Current result · y₀

I lose trip time, accept avoidable uncertainty and may miss remedies or incur expenses before I know who will support me.

Candidate shape · fᵢ(x)

Start with an Amex-assisted, read-only case coordinator: identify provider ownership, verify booking/coverage, assemble evidence, suggest authorized remedies and seek human approval for consequential contacts or changes.

Desired outcome · y

The issue is diagnosed and routed quickly, my options are accurate, and legitimate remedies proceed with less coordination and clear control.

Success check

In actual disruption cases, did coordination and time to a valid remedy improve without unauthorized contacts, wrong coverage advice or added case costs?

Other candidate options: Evidence preparation, proactive status updates, or a scoped handoff between a customer-owned agent and Amex for authoritative case status after identity, provider rights and escalation are demonstrated. Full autonomous rebooking is not the opening shape.

M · What must be true

  • Booking and transaction records can be retrieved with revocable consent.
  • The right provider, claims path and relevant benefit terms are identifiable.
  • Provider actions require a supported integration or human-mediated handoff.
  • Escalation and liability boundaries can be enforced.

R · What any better way must do

Fast valid diagnosisCorrect entitlementsExplicit authorityTransparent statusRecoverable and human-reviewable
Business-value caseTEST

High severity; uncertain frequency/economics · strategic potential, not forecast revenue

How Amex might benefit

Lower support handling burden, faster successful resolution, premium Member trust and possible retention upside.

Business result to measure

Valid-resolution time, net case-handling costs, error rate and repeat contacts; measured against existing Amex service.

What might break this bet

Supplier/insurer controls limit useful action or agent complexity exceeds savings.

Next evidence / decision gate

Start with shadow-mode case classification and evidence capture; authorize provider contact only after entitlement and error gates pass.

Research trail:E010, E011, E012, E013, E014
Execution budgetIllustrative conversion at 40 hrs/person-week, 2× agent production and 25% review; not an approved execution cap.
12 person-wks
Human-equivalent capacity480 hrs
Machine cap @ 2×240 agent-hrs
Human review @ 25%120 hrs
Quality floorReal disruption cases receive a correct, documented classification and authorized next action; uncertain coverage stays uncertain; the traveler can escalate, reverse or take over.
3.2 · Dining DelegateDeferred • only if approved booking handoff still failsHOLD · deferred option Appetite Not assigned Show Frame + Candidate ShapeHide Frame + Candidate Shape
Struggling moment · x

When I have found a genuinely eligible, available reservation, I still lose the table or have to repeat my constraints while completing the booking through a separate approved provider flow.

Current approach · f₀(x)

Follow booking links, re-enter details, wait for confirmations and retry if availability changes.

Current result · y₀

The booking may fail or the intended time/party constraints are lost, despite a feasible recommendation.

Candidate shape · fᵢ(x)

An explicitly authorized Amex/Resy agent completes the reservation through an approved provider interface, confirms critical details and returns a durable record.

Desired outcome · y

A viable table is booked successfully without rework or loss of intent.

Success check

Is the booking-handoff abandonment rate material, and would approved delegated completion improve it without errors or new restrictions?

Other candidate options: Simpler deep linking, prefilled confirmation or guided handoff may resolve the same problem without booking delegation.

M · What must be true

  • A real, repeated and material handoff drop-off exists after feasible discovery.
  • An Amex-approved booking interface permits scoped agency.
  • Cost, cancellation and privacy risk are acceptable.

R · What any better way must do

Approved integrationCorrect bookingExplicit authorityEasy cancellationMeasured incremental completion
Business-value caseHOLD

Low–medium incremental upside pending proof · strategic potential, not forecast revenue

How Amex might benefit

More valid completed bookings, fewer abandonment losses and additional service convenience only if current handoff underperforms.

Business result to measure

Incremental, error-free completions net of liability, API and service costs.

What might break this bet

Current flows already work or unapproved bots are blocked; handoff friction is too small.

Next evidence / decision gate

Prove current drop-off and approved provider capability before assigning appetite; otherwise fold into dining flow.

Research trail:E006, E007, E019, E022
3.3 · Travel DelegateDeferred • multi-supplier autonomyHOLD · deferred option Appetite Not assigned Show Frame + Candidate ShapeHide Frame + Candidate Shape
Struggling moment · x

When several linked travel bookings need to be coordinated or changed, no single party manages the resulting dependencies while preserving my choices and protections.

Current approach · f₀(x)

Book each part through separate tools, reconcile terms and benefits, track confirmations, and manually make routine changes.

Current result · y₀

I spend significant time coordinating the itinerary, with opportunities for missed value, conflicting details, or avoidable errors.

Candidate shape · fᵢ(x)

A scoped Amex agent handles one bounded booking or modification job at a time, with explicit approval, escalation and verified supplier integration; wider autonomy is conditional.

Desired outcome · y

My itinerary is booked and managed coherently with less effort, relevant Membership value, and clear control over consequential decisions.

Success check

Did bounded trip delegation reduce coordination and errors while preserving intended choices, control, and value?

Other candidate options: Start with a narrow cancellation, change alert or approved itinerary reconciliation task. Do not treat end-to-end autonomy as the first build.

M · What must be true

  • Independent provider booking/change interfaces support explicit delegation.
  • Error liability and recovery obligations are understood.
  • Smaller planning and disruption bets demonstrate material value.
  • The Card Member can approve and revoke consequential action.

R · What any better way must do

Narrow authorityProvider supportAccurate termsEscalatableNo adverse surprise
Business-value caseHOLD

Potentially high, unproven · strategic potential, not forecast revenue

How Amex might benefit

Reduced coordination effort and possibly more complete trip services, but negative-error exposure and cost may dominate.

Business result to measure

Net value of error-free authorized jobs and retention/servicing effects less liability and AI costs.

What might break this bet

Rights/access absent, costly failures, limited adoption, or ordinary tools already sufficient.

Next evidence / decision gate

Decompose into proven narrow tasks after travel-value and recovery tests; obtain contracts and risk review first.

Research trail:E001, E013, E015
4

Milestone 4 · Expand Proven Patterns

Enter new experiences only when a distinct struggle is evidenced.

Why here: Do not treat Events or local discovery as automatic next steps. Keep Events on hold; local discovery is a candidate surface in the Offers bet.

1 holdNo appetite assigned
4.1 · Events & ExperiencesDeferred • distinctive access, not generic discoveryHOLD · deferred option Appetite Not assigned Show Frame + Candidate ShapeHide Frame + Candidate Shape
Struggling moment · x

When a limited event or access window opens for something I would attend, I learn too late whether a genuinely better Amex-eligible option is available.

Current approach · f₀(x)

Check ticket and event sites, monitor releases, and separately search for Amex presales, access, or Offers.

Current result · y₀

I may discover an event or eligible access too late, miss availability, or pay more than I needed to.

Candidate shape · fᵢ(x)

An Amex-aware assistant verifies meaningful access eligibility and timing, and surfaces the option while it can still be used; the scope is limited to supply genuinely differentiated by Membership.

Desired outcome · y

I get more relevant experiences and can use the Membership value attached to them.

Success check

Do real Members obtain a feasible experience they could not reasonably secure using the current discovery and access channels?

Other candidate options: A timely eligible-access alert, event-specific inventory panel or customer-invoked agent check for eligible access before any approved purchase flow. Commercial conversion requires a customer-requested task, appropriate permissions and its own incremental-economics test; no unsolicited agent selling.

M · What must be true

  • A first-person repeated missed-access struggle can be reconstructed.
  • Unique and available Amex-eligible inventory exists beyond generic event search.
  • Consent-based timing and notifications work without excess noise.

R · What any better way must do

Verified eligibilityDistinctive accessTime-sensitiveLow noiseUseful outcome
Business-value caseHOLD

Plausible, weak direct evidence · strategic potential, not forecast revenue

How Amex might benefit

Exclusive access utilization, partner engagement and Membership preference if supply actually differs.

Business result to measure

Verified incremental attendance/access use and any attributable Member economic effect.

What might break this bet

Inventory is not distinctive or notifications do not change behavior.

Next evidence / decision gate

Collect observed missed-window episodes and confirm actual Member-only inventory before making it an independent bet.

Research trail:E001, E016

How to read it: A thematic sequence of candidate problems, not a committed calendar plan. TEST means investigate through a bounded evidence move; HOLD is not authorized scope. Each card preserves the problem frame, one illustrative candidate shape, success check, eventual actual result, M, R, quality floor, and a research-informed business case. The four existing draft TEST appetites sum to 51 person-weeks; the new Benefit Outcome Assurance appetite remains to be judged. Local Membership Layer has been merged into the Offers candidate surfaces.

← Roadmap1.1 · Working research & shaping✕

AUTOMATIC OFFERS · 1.1

Shaping & v1

Comprehensive candidate shaping, with explicit decision gates. Nothing here changes the status or budget of the roadmap bet.

3 wks × 3 · Draft9 person-wksR0–R7 · WorkingShapes A / B / CNot selected

Executive decision

Current state: Working frame + Working R/Appetite + unselected candidate shapes. Current recommendation: run a bounded test, not an authorized build. 3 weeks × 3 people = 9 person-weeks is a draft appetite.

Most important finding: Current Amex terms require pre-purchase enrollment on the eligible Card and prohibit unauthorized automated enrollment. A first-party approved action may be possible, but its specific permission/API and merchant economics have not been verified. The design must not silently assume this capability.

Recommended next evidence: Verify an approved enrollment pathway (SP1) and whether an incremental-contribution controlled trial is feasible (SP3). If either fails, do not force a v1 enrollment build. Do not use CardPointers-style existing functionality as a novelty claim.

Result: Frame (x → ? → y), R0–R7 working criteria, CURRENT/A/B/C alternatives, working binary Fit Check, Rotated Fit, appetite cuts, candidate B breadboard and conditional v1 examples. Selected shape: none. Build authority: none.

01Problem & frame⌄

Automatic Offers 1.1 — Frame

Purpose & boundaries

Use when: judging any shape for the purchase-time Offers struggle. Must preserve: exact triggering moment, current Amex enrollment requirements, difference between benefit realization and merchant incrementality, consent and merchant restrictions. Do not treat: a candidate automation mechanism, a customer forum post, or program scale as approved product intent or causal demand evidence.

Source — kept separate from interpretation
  • S1 · This roadmap / 1.1: The current working struggle, illustrative candidate, operating conditions, criteria, quality floor and 3-week × 3-person draft appetite. This is a planning hypothesis, not observed customer behavior.
  • S2 · U.S. Amex Offers Program Terms, July 2026: Enrollment precedes a qualifying purchase, normally on the same eligible Card; automated enrollment by unauthorized tools is prohibited; account and merchant eligibility, exclusions, caps, expiration, and fulfillment conditions matter. Official terms.
  • S3 · Amex merchant program: 2025 $21B U.S. / $24B worldwide in Offer-associated merchant spend and 464M U.S. enrollments. Neither indicates incremental spend or unique active people. Merchant source.
  • S4 · Existing competing workaround: CardPointers offers browser/safari contextual surfacing and automated syncing / adding, including newer in-app syncing. Claimed functionality is supplier evidence, not proof that its practices are approved under Amex terms or that it improves economics. Extension, newer in-app syncing.
  • S5 · Open business questions for this bet: How often do people miss eligible Offers, can timely guidance change purchases rather than simply increase discount use, and will the result improve net contribution after costs? These remain to be tested.
Pre-work / competing problem directions

The adjacent Benefit Outcome Assurance bet begins after an eligible transaction or benefit fails to materialize; it is not this work's scope. Local relevance is one possible context for the purchase-time struggle, not another automatically funded feature. The immediate decision is whether the purchase-time gap merits a limited causal test against current Amex and third-party workarounds.

Current situation · x
  • Who: U.S. consumer Card Member targeted for an Offer who is approaching a purchase decision; frequency and reachability are UNKNOWN.
  • Trigger: At or shortly before payment at a potentially qualifying merchant, on a channel in which purchase context could be detected with permission.
  • Current approach: Check the Amex app or online Offers portal, interpret merchant terms, enroll in a targeted Offer on the right Card before the purchase, then remember to pay with that Card. Alternatively, use an existing third-party reminder/offer-management workflow.
  • Current result: Some customers spend attention on searching and remembering; others can miss eligible value. We do not yet know how frequently this happens, how much value is missed, or which alternatives they already use.
  • Breakdown: The moment of decision is separated from the moment of discovery, eligibility determination, enrollment, and Card choice.
Frame transformation

x → f() → y, with f() intentionally UNSPECIFIED.

Desired outcome · y: At the relevant purchase decision, a person can confidently realize legitimate, applicable Membership value with less manual coordination, without inaccurate eligibility claims or unexpected enrollment, and without Amex destroying net merchant/member economics.

Gap: timely usable value, compliant action where permitted, and verifiable real-world impact must come together instead of separate remembering and guesswork.

Problem

The system places the burden of finding, interpreting, enrolling and remembering targeted value on the Card Member at a moment when the benefit may matter. We have not established that an agent or auto-enrollment is the best answer or that more enrollment creates incremental spend.

Operating model · M (Working)
  • M1 · VERIFIED external condition: Current published U.S. terms require enrollment before the qualifying transaction, on the eligible Card, and restrict unauthorized automated enrollment. Source S2.
  • M2 · VERIFIED external condition: Offer eligibility, merchant terms, exclusions, expiration, merchant coding and redemption recognition can vary. Source S2.
  • M3 · VERIFIED program scale, not outcome effect: Amex reports Offer-associated spend and enrollments; campaign incrementality cannot be inferred. Source S3.
  • M4 · VERIFIED competing behavior available, not regulatory permission: CardPointers surfaces offers contextually and offers auto-sync; the incremental unsolved gap needs direct comparison. Source S4.
  • M5 · ASSUMPTION / INTERNAL CONFIRMATION NEEDED: Amex can provide approved merchant-context signals, first-party offer eligibility/enrollment status, auditable permission and experiment-level economics within one pilot surface.
  • M6 · ASSUMPTION / INTERNAL CONFIRMATION NEEDED: A safe trial can randomize or otherwise validly identify incremental outcomes net of subsidy, cannibalization and servicing cost.
  • Staleness triggers: revised U.S. terms, Amex first-party capabilities, merchant campaign contracts, competitor functionality, privacy policies or account targeting policies.
Outcome and boundaries

Success at effect altitude: verified incremental merchant-valued outcomes and/or meaningful Card Member savings/effort reduction relative to matched current flows, with no hidden eligibility, consent, budget or recourse regression. Do not assert effect without randomized or defensible controlled evidence.

Less about: bulk adding everything; new coupon catalog; universal browser extension; scraping credential-protected screens; assumed AI autonomy; click-through or gross redemption counts as proof of value.

More about: purchase timing; accurate and explainable eligibility; first-party permissions and merchant terms; Card Member control; causal incremental contribution; reversible errors and clear uncertainty.

Preliminary criteria candidates

R0 outcome realized; R1 term and Card correctness; R2 purchase-time relevance; R3 permitted action; R4 user control; R5 truthful non-intrusive explanation; R6 traceable outcomes; R7 causal net economic test. All are Working, not accepted.

What is unknown and could falsify this frame
  • How many eligible purchases feature a genuinely overlooked relevant Offer, vs an already-enrolled offer? Unknown.
  • Whether CardPointers or Amex improvements have already substantially solved the pain for the pilot segment. Unknown.
  • Whether most Offer-associated purchases would have occurred anyway. Unknown; fatal to an incremental-spend claim if yes.
  • Which Amex-owned surface has approved timing and enrollment rights. Unknown.
  • Whether an intervention causes excessive alerts, mistrust, wrong-Card payment or higher subsidy. Unknown.

Authority: Working candidate frame. A human must accept/revise the boundary before shape selection or approved build scope.

02Requirements, appetite & shapes⌄

Automatic Offers 1.1 — Comprehensive Shaping

Purpose & boundaries

Governing rule: Exploration is fluid. Commitment is gated. Status: collaborative S-first + evidence-first shaping; human selection NOT made. Must preserve: R0–R7 identities and source origins, three different candidate families, the draft 3-week/3-person appetite, rejected/unknown parts, and the distinction between design fit and effect evidence. Never treat these working tables as implementation scope.

Frame reference

automatic-offers-frame.md · Working. x: a potentially eligible purchase approaching checkout, value hidden behind an earlier enrollment + Card choice. f(): UNSPECIFIED at frame altitude. y: confidently realized relevant value with reduced effort and valid economics. M: M1–M6 (official terms vs uncertain internal rights). Scope: U.S. consumer Amex Offers, one approved pilot channel and narrow cohort if authorized.

Requirements (Working; not accepted)
ID Requirement (mechanism-free) Status Authority Origin Evidence / constraint
R0 At the relevant purchase moment, Card Member can realize valid Membership value without a separate search-and-remember task. Core goal Working FROM_Y S1, S5; effect unproven
R1 Any surfaced offer/value must be accurately eligible for the merchant, Card, account, terms and purchase timing; unknown means no promise. Must-have Working FROM_M S2
R2 Relevant help must arrive with enough time to take a permitted action before purchase, without material noise. Must-have Working FROM_X S1; timing feasibility unknown
R3 The product cannot take an enrollment or other consequential action without a channel authorized by Amex and an appropriate, bounded grant. Must-have Working FROM_BOUNDARY S2
R4 The person controls which Card/Offer is acted on, can decline, and can withdraw any standing permission. Must-have Working FROM_BOUNDARY S2; user-control design implication
R5 The experience clearly distinguishes confirmed eligibility, tentative match, enrollment status, and unavailable/expired conditions. Must-have Working FROM_GAP S2
R6 Actions and their outcomes can be traced, including failure, no-action, and later verification where data permits. Must-have Working FROM_Y S2; audit/recovery inference
R7 The intervention can be compared with current and strong third-party baselines on incremental member and merchant value net of subsidies, displacement, tool and servicing cost. Must-have Working FROM_Y S3–S5; causal data needed

No requirement prescribes a browser extension, enrollment endpoint, model, UI framework, or agent.

Appetite, team, cut line
  • Authority: Working / provisional, inherited from roadmap; not human-accepted.
  • Product appetite: 3 calendar working weeks × 3 people = 9 person-weeks; value judgment to be ratified by a decision owner, not an effort estimate.
  • Review: end of the bounded bet, with early stop at SP1/SP2 if no approved surface or data. Machine execution/review translation is optional and needs actual observed production/review factors; don't treat 2× and 25% as commitments.
  • Keep above cut line only if supported: one approved channel, one bounded cohort/merchant offer family, truthful pre-purchase matching, user-authorized next action, status and instrumentation, defensible holdout readout.
  • Cut first: multi-merchant coverage, cross-device sync, geo detection, autonomous card choice, background enrollment, broad notification system, merchant onboarding console, personalized ranking beyond confirmed simple relevance.
  • Never cut to fit: eligibility and same-Card constraints; official authorizations; honesty of state; consent; audit evidence; quality floor; economic falsification.
  • Accepted uncertainty: impact size and desirability may remain unknown at beginning of a nontransactional pilot.
  • Must-resolve before transactional B/C: contract-approved first-party action, cohort access, merchant budget controls, error/recovery plan and experiment design.
  • Revisit: human changes outcome/hurdle; no authorized surface; economic test not feasible; CardPointers/current baseline erases differential; 3-week cap approached.
CURRENT — baseline and comparator
Part Mechanism / reality Notes
CURRENT1 Amex targeted Offer appears in designated Amex channels Source S2
CURRENT2 Member adds to one eligible Card before purchase Source S2
CURRENT3 Same Card and applicable transaction terms determine fulfillment Source S2
CURRENT4 Third-party products can auto-add/sync and remind at merchants Source S4; authorization of a particular behavior NOT established
A — First-party contextual guide (no delegated enrollment)
Part Mechanism Flag
A1 Receive approved purchase-context indication for eligible pilot channel ⚠️ internal signal existence
A2 Match potential offers and Card; show eligibility/uncertainty and key terms ⚠️ internal eligibility data
A3 Present clear pre-payment reminder, with link to the existing Amex enrollment channel Working
A4 Track exposure, confirmed enrollment if available, opt-outs and controlled business outcome ⚠️ internal metric access

Advantage: least new authority, plausible low-risk shadow or simulated test. Against: still requires a separate manual enrollment step; may fail R0; competitor already offers reminders. Cut: no extension and no background actions.

B — First-party just-in-time enrollment (explicit bounded instruction)
Part Mechanism Flag
B1 First-party approved shopping/context entry → secure Amex session ⚠️ approved signal/path
B2 Validate targeted offer, eligible Card, merchant/transaction restrictions and enrollment state ⚠️ product data and real-time certainty
B3 Show offer terms, expected conditional value, precise Card, and explicit confirmation Working
B4 Invoke Amex-authorized first-party enrollment on that Card; never third-party credentials/bot ⚠️ internal action rights and approval
B5 Return success / pending / failed / already enrolled / unavailable, with no false promise of credit ⚠️ state/settlement visibility
B6 Create a consent-and-event record with experiment assignment, limited retention, no sensitive merchant leakage ⚠️ governance / analytics

Advantage: could eliminate the actual last-mile activation chore at checkout. Against: may not be permitted in proposed pilot surface; instant enrollment guarantee and merchant match remain unknown; likely too much for 3 weeks absent existing sanctioned APIs. Cut: any unapproved enrollment and all autonomous bulk activation.

C — First-party standing enrollment rule (pre-purchase opt-in)
Part Mechanism Flag
C1 Member defines limited rule for permitted targeted Offers / Cards ⚠️ policy fit
C2 First-party Amex rule evaluator enrolls qualifying targeted Offers before transactions ⚠️ contract/policy, capacity, enrollment caps
C3 Member views history, suppresses or revokes policy, receives suitable alerts ⚠️ governance and audit
C4 Economic guardrails stop campaign overspend / nonincremental enrollment ⚠️ data and causal validity

Advantage: eliminates remembered action entirely. Against: much broader authorization/economic exposure; technically resembles already available third-party automation, but with first-party advantages unproven; likely beyond 3-week evidence appetite. Cut: not v1 unless separate approval and a new bet.

Rejected non-serious direction: automatic post-transaction credit without prior enrollment contradicts present terms (S2), unless terms are explicitly changed. Do not make it a silent v1 behavior.

Working Fit Check — Requirements × candidate shapes

Evaluation: design-conformance hypothesis only. ✅ means the drawn mechanisms plausibly address R; ❌ includes unknown/unverified prerequisites. No shape is selected or decision-ready. The frame and relevant M are held stable.

Req Requirement shorthand CURRENT A B C
R0 Value without separate search/remember ❌ ❌ ✅ ✅
R1 Proven eligibility, same Card, terms ✅ ❌ ❌ ❌
R2 Pre-purchase contextual timing ❌ ❌ ❌ ❌
R3 Authorized consequential action ✅ ✅ ❌ ❌
R4 Person control / decline / revoke ✅ ✅ ✅ ❌
R5 Clear eligibility and status, including unknown ❌ ✅ ❌ ❌
R6 Evidence of actions and outcomes ❌ ❌ ❌ ❌
R7 Measurable incremental net value ❌ ❌ ❌ ❌

Why so many ❌: B has attractive mechanism coverage but no verified rights, eligibility freshness, settlement and outcome instrumentation. A's ability to route to enrollment does not fulfill the no-separate-task requirement. The zero passes in R7 reflect missing experiment data, not proof of zero value. Unknown must not be upgraded to a pass. Fit never proves realized customer or business effect.

Rotated Fit Check — B parts × requirements (Working, NOT selected)
Part Mechanism Claims to serve Justified conceptually? Open issue
B1 Approved purchase trigger R0,R2 ✅ channel feasibility unknown
B2 Check merchant/Card/offer eligibility R1,R5 ✅ insufficient live data possible
B3 Explain terms, request confirmation R3,R4,R5 ✅ whether amount/qualifying purchase known
B4 First-party enrollment call R0,R3 ✅ critical overloaded risk: rights, latency, state
B5 Display truthful resulting state R5,R6 ✅ later redemption not equivalent to enrollment
B6 Consent and experiment trace R4,R6,R7 ✅ privacy governance and lift metric absent

Reverse-fit issues: B4 carries outsized compliance/technical responsibility. B2 and B5 may duplicate eligibility/status decisions; choose a canonical source if selected. R7 requires an independent holdout/outcome measurement capability—not merely B6 event logging. R1 is not established by listing B2. No unjustified feature should be smuggled in as “AI.”

Appetite fit (Working / conditional)
Shape Within 3-week × 3-person appetite? Required cuts Needed spike / decision
A ❌ One pilot channel, no extension; still needs measurable business readout SP1, SP2, SP3; currently no evidence of access or full R0 fit
B ❌ Single authorized merchant/offer family, explicit confirmation only SP1, SP2, SP3; approved enrollment + data must exist
C ❌ Standing rules would be removed, changing the shape New policy/economic bet required

No ✅ until access, outcome measurement, safety and capacity are established. If no shape fits: investigate, reduce to a separately accepted evidence-only bet, revise appetite through a human decision, or stop. Never silently rebrand a guidance-only test as complete automatic enrollment.

Generation-omission check

Families considered: guidance (A), approved just-in-time action (B), preauthorized standing action (C). Existing comparator (CURRENT) includes CardPointers. A missing family is network/merchant-driven automatic application at settlement; present published enrollment-before-purchase terms make it non-viable under present assumptions. Another is a purchase receipt scanner after payment, which cannot cure lack of prior enrollment. Omission risk: material until internal Amex capabilities/terms are inventoried.

Focused spikes and test-return contracts
ID Narrow investigation Trigger Minimum result / stop Planning consequence
SP1 Confirm first-party Offer-enrollment authorization, allowed surfaces, merchant constraints, post-action state API B4, R1,R3 Written yes/no/conditional policy and engineering owner; if unavailable, B/C fail Refit B/C; do not code unapproved action
SP2 Verify available real-time merchant-context, Card eligibility, data latency and opt-in consent A1/B1/B2, R1,R2 One documented source and failure modes, or infeasible verdict Refit A/B + M5
SP3 Obtain randomized/control and contribution measurement design with merchant funding, baseline spend, cannibalization and cost R7, B6 Named analytics/merchant owner, feasible eligible cohort, leading + lagging measures Decide whether evidence-only bet has value
SP4 Validate offer status, failed/pending paths and later settlement truth B5, R5,R6 Source for enrollment state and defined unknown/recovery behavior Refit B and candidate breadboard

Spikes gather facts. They do not choose the shape; stop when the named question is answered or bounded.

Decision and human gate
  • Status: EXPLORING / not decision-ready; chosen direction: NONE.
  • Before shape selection: human must accept/revise frame, R0–R7, 3-week × 3-person appetite and cut line; SP1–SP3 must provide enough evidence to compare honestly; then explicit human choice A/B/C, iteration or stop.
  • After selection: reconcile candidate breadboard into selected-design, human accept; only then derive implementation vertical slices / Dumplink / context packet. No task-group or slice is authorized by this document.
  • Next useful move: SP1 and SP3 in parallel if owners and access exist; if their fatal gates fail, stop transactional B rather than filling the remainder with speculative UI work.
03Candidate breadboard⌄

Automatic Offers — Candidate Breadboard B (exploratory)

Candidate status & limits
  • Mode: candidate-shape, NEVER selected-design.
  • Candidate: B · first-party just-in-time enrollment; parts B1–B6.
  • Question: Can one first-party shopping signal lead to a truthful, permitted pre-payment enrollment/result without unauthorized automation or misleading eligibility?
  • Requirements / appetite: Working R0–R7; Working 3 weeks × 3 people. Candidate only. The tables are illustrative and contain unresolved gaps.
  • Authority: shaping comparison only. No build/slicing permission.
Places
ID Authority Shape part Place Responsibility
P1 candidate B1 Approved purchase context An authorized first-party purchase-intent surface, not arbitrary browser scraping
P2 candidate B2,B3 Amex Offer decision Show matched targeted eligibility, terms, Card and confirmation
P3 candidate B4,B5 Amex Offer enrollment service Sanctioned enrollment action and accurate resulting status
P4 candidate B6 Trial instrumentation Consented exposure and action/outcome trace, controlled measurement
UI affordances
ID Place Part User-facing affordance Wires out Returns / observable consequence
U1 P1 B1 "Possible offer for this purchase" or silent no-match N1 U2 or no nudge
U2 P2 B2,B3 Merchant, eligible Card, limitations, tentative status U3 / N2 Accurate explanation or unavailable
U3 P2 B3 Explicit "Add this Offer to this Card" / decline N3 U4 or dismiss
U4 P2 B5 Confirmed enrollment / pending / failed / unavailable / already enrolled — no promise of redemption
U5 P2 B5 "View conditions / check status" N5 truthful status and support route
Non-UI affordances
ID Place Part Consequential behavior Wires out Returns to
N1 P1 B1 Validate consented purchase-context / merchant match N2 U1
N2 P2 B2 Lookup current targeted Offer, Card, restrictions, expiry, enrollment S1,S2 / N3 U2
N3 P2 B3 Enforce allowed enrollment and explicit scoped confirmation N4 or stop U3/U4
N4 P3 B4 Request sanctioned first-party enrollment before payment S2 / N5 U4
N5 P3 B5 Reconcile returned status; preserve unknown if inconsistent S2 / N6 U4/U5
N6 P4 B6 Record only permitted exposure, cohort, action and result S4 analysis result (not automatic product truth)
Stores
ID Place Status Data and writer/reader
S1 P2 ⚠️ UNKNOWN interface First-party targeted Offer terms/eligibility; N2 reads
S2 P3 ⚠️ UNKNOWN interface First-party enrollment/status; N4 writes only if sanctioned, N2/N5 read
S3 P2 ⚠️ UNKNOWN governance Customer consent/decline; N3 reads, explicit customer action writes; revocation behavior needs confirmation
S4 P4 ⚠️ UNKNOWN analytics Consent-safe experiment and audit trace; N6 writes, analytics reads
Product-relevant branches
Trigger / decision Consequence State
No matched targeted Offer or uncertain merchant No offer promise; optionally no nudge Working
Offer shown but Member declines No enrollment; no inferred standing permission Working
Wrong Card / expired / targeted limit exhausted No action; reason given where safe/known Working
Approved enrollment returns pending Display pending; do not claim success or later statement credit Working
Enrollment fails, times out, or loses signal Non-success state, safe retry only if sanctioned and idempotency defined GAP — SP4
Enrollment confirmed, later purchase does not qualify Explain separate transaction-term checks and support path GAP — benefit-assurance boundary
Behavior traces (IDs are structural only; not test results)
Scenario Entry and control Consequence / unresolved
BT1 · valid path P1 U1 → N1 → N2 → P2 U2 → U3 → N3 → P3 N4 → N5 → U4 → N6 Conditional confirmed pre-payment enrollment; authorization and status API unresolved
BT2 · not eligible P1 U1 → N1 → N2 → U2 "not eligible / unknown" No enrollment, no misleading value promise
BT3 · decline P1 U1 → N1 → N2 → U2 → U3 decline → N6 No action; no standing consent inferred
BT4 · timeout U3 confirm → N3 → N4 timeout → N5 → U4 pending/error Idempotency/retry, audit and reconciliation remain gap
Candidate visual / causal rail

P1 Authorized purchase signal → P2 Confirm eligibility and explicit permission → P3 Sanctioned enrollment (or no action) → P4 Audit + controlled outcome, with a local branch at P2 for unknown, declined, wrong Card or expiry.

Breadboard → shaping implications
  • R1,R3,R5 must remain hard constraints. Read-only guidance A is a separate family; do not silently reclassify an enrollment failure as completed automation.
  • B4 is an overloaded boundary: permission, merchant terms, race with checkout and state reporting. Split interface understanding (SP1/SP4) before any claim of appetite fit.
  • R7 is not implemented by an event log alone: independent causal assignment, net contribution definitions and merchant budget rules are needed.
  • M5 remains unverified: if no approved context signal or enrollment action, B is not a viable v1.
  • No selected-design acceptance, committed task group or executable contract. Stop and return to shaping after SP1/SP2/SP3.
04Conditional v1 proposal⌄

Automatic Offers — v1 Candidate Specification (not build authority)

Authority and purpose

Not a selected v1. This document is a comparative and behaviorally concrete v1 candidate so the team can make a human shape decision. Per the planning repository, a committed v1 with vertical slices, interfaces, statechart and execution handoff requires accepted frame, R, appetite, explicit selected shape, reconciled accepted selected-design breadboard and selected slice. Those gates are not met.

Purpose of a bounded v1: determine whether correctly timed, approved Amex-specific help creates incremental business outcome and lower member effort relative to current Amex and robust third-party comparators, not merely more redemptions. The current roadmap's 3-week × 3-person appetite is a draft value judgment, not guaranteed build feasibility.

Decision branch: which v1 is even legal and feasible?
  • Route V1-B / conditional: an Amex-owned, approved first-party signal and sanctioned Offer-enrollment API both exist, real-time eligibility/status and treatment/control metrics are available, and SP1–SP3 clear. Show a single context-relevant targeted Offer and request explicit authorization to enroll on one selected eligible Card before purchase; show resulting state. No merchant checkout or payment action by agent.
  • Route V1-A / narrower evidence-only: if enrollment rights fail but data + approved surface exist, test the nontransactional purchase-time contextual guidance against existing Amex and CardPointers-like behavior. V1-A does not fully meet R0; the human must explicitly revise the v1 promise or stop. Never label it "automatic enrollment".
  • STOP: no authorized purchase-context signal; eligibility accuracy unverifiable; no controlled measurement; no responsible budget/legal approver; no consent/recovery path. Do not substitute scraping/credentials or fake economics.
Proposed v1-B boundary (strictly conditional)

In: one Amex-approved channel; one small targeted cohort; one verified merchant/Offer family; one eligible U.S. consumer Card; before-purchase context; clear terms; explicit per-action enrollment; consent-safe event trail; outcome measurement; no promise that a qualifying credit posts.

Out: universal browser extension, bulk enrollment, auto-choosing a payment card, transaction initiation, location surveillance, multi-card auto-apportionment, supplier-side API scraping, cross-domain shopping history, hidden standing authority, claim automation, AI recommendations based on unverified merchant economics, multi-merchant catalog and paid promotions untested by holdout.

Possible demo (conditional, sandbox/pilot): At a supported merchant, a consented Card Member with a qualifying targeted Offer sees an accurate notice; reviews exact Card and terms; explicitly consents; Amex-authorized enrollment returns a true status before payment. With expired, uncertain or wrong-Card terms, no action occurs. All branches produce independently auditable pilot events.

Actors and permissions
  • Card Member: can view, confirm or decline; grants bounded Offer-specific permission; sees accurate result, can stop/withdraw standing context access where applicable.
  • Amex first-party Offers system: authority on eligibility, enrollment and terms. Permissions not yet verified.
  • Merchant campaign owner / legal / compliance: approve campaign constraints, funding/caps, eligible test and policy controls.
  • Experiment owner: specifies randomization, comparator, net economics and safety thresholds; can halt test.
  • Shopping context provider: explicit approved pilot channel only; avoid unapproved extensions/credential harvest.
Proposed visible behavior (V1-B)
Ref Moment Visible behavior Guard Consequence
V1-01 Purchase-context detected Either no notice or "A possible Amex Offer may apply" context permitted; specific merchant match verified view U1 or no-action
V1-02 Review Merchant, Offer wording, eligible Card, expiry, restrictions and status targeted eligibility currently verifiable show U2; no generalized promise
V1-03 Confirm One-off action "Add Offer to Card ending ••••" exact Card, terms acceptance, valid permission and official action path authorized N4 or explicit no-action
V1-04 Result "Enrolled", "Already enrolled", "Pending", "Failed" or "Not available" truthful first-party response U4; never claim purchase qualified
V1-05 Purchase Card Member checks out independently same Card and transaction terms apply no agent payment or card switch
V1-06 Follow through Offer status check if first-party data available no fabricated settlement/credit certainty audit/receipt or explicit unknown
Negative and edge-case fixtures (planned checks, not executed tests)
Case Setup Required result
EX1 Matching merchant, eligible Offer/Card, explicit confirmation, authorized action correct Card enrolled pre-purchase; receipt shows enrollment only
EX2 Offer targeted to another Card / expired / enrollment cap no action; no incorrect reward estimate
EX3 Merchant alias or payment processor cannot be verified uncertainty state; no claim that payment qualifies
EX4 Customer declines, consent is absent or revoked do not enroll or retry
EX5 Enrollment timeout / duplicate submit / response ambiguity no double action; pending/error with supported recovery; unresolved until SP4
EX6 Enrolled Offer, later purchase fails merchant terms enrollment success must not masquerade as reward success; benefit assurance distinct
EX7 Control/holdout eligible event collect only approved comparator/assignment data; no intervention
EX8 Multiple Offers could apply, ranking economics unknown no invented "best offer" label; present a narrow verified choice or no recommendation
Quality floor — mandatory, not a best-case target
  • Zero unapproved enrollment; no unauthorized bot, credential automation or merchant data exfiltration.
  • No false eligibility, false Card, false enrollment, false fulfillment or false savings claims in checked fixtures.
  • Human-visible control before consequential action, with no inferred broad permission.
  • Every relevant error/timeout/unavailable condition yields safe and comprehensible no-action/pending behavior.
  • Independent ability to attribute intervention and measure meaningful pilot outcomes under agreed privacy/campaign limits.
  • Guardrail violations pause the test; failure to meet the floor is NOT repaired by adding weeks.
Business experiment / causal readout contract (proposed)
  • Unit: eligible purchase decision or targeted Offer/merchant opportunity, with clearly defined randomization and attribution. Not all Amex cardholders.
  • Primary: incremental net contribution per eligible purchase opportunity, comparing intervention and control, after merchant-funded discount/subsidy, cannibalized organic purchases, campaign expense, tooling and human service/error costs. Internal accounting owner must agree inclusion/exclusion.
  • Card Member effect: verified savings realized where eligible, effort/time reduction, wrong-Card and incorrect-discount incidents, complaint rate; no fabricated survey result.
  • Safety/quality: authorized-action breaches, eligibility misclassifications, unwanted enrollment, support escalation, merchant limits, false promises; explicit preapproved stop thresholds needed.
  • Comparators: current Amex app/web behavior and a strong third-party workaround (CardPointers-style) where ethically and feasibly comparable; do not assume comparator has equivalent access/rights.
  • Cannot claim: $21B associated U.S. spend as causal uplift; 464M enrollments as unique people; increased enrollment/redemptions as proof of contribution; a hypothetical scenario as measured conversion data.
  • Statistical plan: define treatment population, sample adequacy and power from internal baseline; avoid inventing conversion, lift or significance here. Randomize at a contamination-resistant unit per analytics review. No pre-registered metric/threshold is available yet.
Scope cut and stop protocol
  1. Cut personalization, ranking and surface expansion first; keep rules/eligibility correct.
  2. If merchant context is unreliable, restrict to explicit declared merchant intent (human revision may be required if value proposition changes).
  3. If first-party enrollment authority fails, stop B; only explore A with separate human approval and honest new goal.
  4. If controlled incremental economics cannot be observed, stop calling it a validated economic test; return to the business-value assessment.
  5. At the approved appetite cap, stop, verify what is true, preserve state and request a new bet if more capacity is desired.
Unresolved human decisions required for v1 approval
Gate Who decides Required outcome
G1 Product sponsor Accept/revise frame and bounded outcome, including who benefits
G2 Product + risk + merchant/legal Accept R0–R7 and actual authorized action/surface
G3 Product sponsor + delivery team Accept 3-week × 3-person appetite, cut line and review point, or revise budget
G4 Product owner Select A, B, C or stop based on working fit after SP1–SP3
G5 Product + design + engineering Reconcile selected-design breadboard; accept concrete behavior and error semantics
G6 Product + analytics Approve test power, quality thresholds, and causal / P&L readout
G7 Human owner Approve vertical slice / Dumplink groups after selected design; no implementation before this gate

Status at delivery: G1–G7 NOT RECORDED AS ACCEPTED; human review needed. No production code, committed task decomposition, contract or selected-design statechart generated by this exercise.

Human gate remains open. No direction was selected for you. Review the frame, requirement authority, budget and what we must learn before selecting a shape or authorizing v1 implementation. Return to the roadmap ↑