Book a working session

Example run

Explore an example from signal to decision.

A sample payment-recovery case showing diagnosis, evidence, solution options, engineering handoff and measurement. Illustrative data and interactions—not a client result or a live ROQIVA deployment.

Signal map

Trace the signals no decision reads.

A solid line is read. A dashed line is a gap. Code does the matching, so the same exports always give the same map.

Sample case · A payment failure code is recorded, but the CRM retry decision does not use it. Follow the evidence, proposed intervention and measurement approach. This is an illustrative scenario, not a client result.

WI-014DetectorsSignal map

  1. payments.failure_codePaymentsCaptured, never read by CRM retry rule.
  2. orders.statusOrdersRead by Customer messages.
  3. orders.courier_delayOrdersCaptured, never read by Customer messages.
  4. search.zero_result_termSearch logCaptured, never read by Range planning.
  5. customer.idAppRead by CRM audiences.
  6. storefront.notify_meStorefrontCaptured, never read by Restock messages.
6 of 6 matched · 2 read · 4 gapsRead by a decisionCaptured, never read

Finding card

Read a finding card, field by field.

One page, one problem, seven fields. Your PM decides at Gate 1 without reopening the data.

Two lanes: incidents (a live break) and opportunities (upside). Priority = value × confidence ÷ effort.

F-001 · Incident lane

Failed payments get one retry

ExpectedWhat should happen
A payment failure reason changes how the failure is retried.
ObservedWhat actually happens
Gateway failure codes are captured on every attempt, but the CRM retry rule treats hard, transient and bank-side failures the same.
SourcesWhere the evidence comes from
Payments export. CRM retry-rule configuration.
Evidence labelHow proven it is
SupportedThe evidence is consistent, but the counts are not yet reproduced.
Value rangeWhat fixing it could be worth
Not sized in this illustration. A real card gives a range from the brand’s own numbers, labelled by proof level. Never a single promise.
Effort and ownerWhat it costs and who must act
An engineering estimate, and the team that owns the retry rule.
Not seenWhat the Analyst could not inspect
Card-network decline reasons were not in the export. Unseen is never reported as healthy.
Try each label

This example is illustrative. It is not a finding for any brand.

Ranking

Rank findings in two lanes so upside never hides a break.

Priority = value × confidence ÷ effort, each rated 1 to 3. Code computes the order. Ratings here are illustrative.

Incidents

A live break. Fix first.

  1. 1

    F-001 Failed payments get one retry

    Payments → CRM retry rule

    Value 3 × Confidence 3 ÷ Effort 1

    9.0
  2. 2

    F-004 Courier delay events unused

    Orders → customer messages

    Value 2 × Confidence 3 ÷ Effort 2

    3.0
  3. 3

    F-006 City stock shown as one national total

    Inventory → product page

    Value 1 × Confidence 3 ÷ Effort 2

    1.5

Opportunities

Upside. Plan next.

  1. 1

    F-002 Zero-result searches never reviewed

    Search log → range planning

    Value 3 × Confidence 2 ÷ Effort 2

    3.0
  2. 2

    F-003 Notify-me sign-ups never read

    Storefront → restock messages

    Value 2 × Confidence 1 ÷ Effort 1

    2.0
  3. 3

    F-005 COD rule with no refusal history

    Orders → COD eligibility

    Value 1 × Confidence 2 ÷ Effort 2

    1.0

Solutions

Compare three solutions, including the cheapest.

Research, Architect and Product draft in parallel. Your people choose at Gate 2.

WI-014Product agentSolutions

Solutions for WI-014Drafting3 solutions

AConfigureCheapest

Branch the existing retry rule on failure type

+Reuses the rule and the captured failure codes.

−Only as good as the codes the gateway sends.

BBuild

Build a dedicated retry service

+Full control over timing and channels.

−The longest path to ship.

CRun manually

Have ops reprocess failed payments daily

+No engineering needed.

−Does not scale past a few cases.

Evidence: Supported. People choose at Gate 2.

Gate 2PM and leads pick the solution.Pick AWaitingPicked A

PRD and wireframe

Review the PRD and wireframe before Gate 3.

Every requirement maps to a screen. Gate 3 releases the whole pack.

WI-014Product agentPRD.md

PRD.mdEmptyWritingDraft v1RevisingDraft v2

Retry failed payments by failure type

Owner · Your PMWI-014Gate 3

01Problem

The CRM retry rule treats hard, transient and bank-side failures the same. Gateway failure codes are captured and never read.

02Goal

Retry each failure type the way it should be retried, and leave unrecoverable failures alone.

03Requirements

  • R1Capture the failure class on every failed payment attempt.
  • R2Retry transient failures once, after a short delay. Never retry a hard decline.
  • R3Show an error state with a next action for hard and transient failures.Show an error state with a next action for hard, transient and bank-side failures. Changed

    Your PMCommentResolved

    Bank-side failures have no error state. Add one.

    Comment

  • R4Send retry_attempted and retry_result with the failure class.

04Metrics

North star
Orders recovered from failed payments
Input
Retry success by failure type
Guardrail
Duplicate charges, complaint rate

05Tracking

  • retry_attemptedA retry starts
  • retry_resultA retry ends
  • failure_classOn the order event

06Acceptance

  • Tracked events fire on retry
  • The failure path completes
  • The screen matches the wireframe

07Open questions

Open Card-network decline reasons were not in the export. Who owns them?

Gate 3PM, designer and engineer review the pack.Not sentWaiting for review

Release

Verify the release before it ships.

A failed check blocks release.

WI-014QA agentRC-1

QA report · RC-1RunningBlockedChecked

2 passed · 1 failed · 2 not tested3 passed · 0 failed · 2 not testedRelease blockedReady to sign

  • Tracked events fire on retryPassed
  • Failure path completesPassed
  • Screen matches the wireframeFailedPassed
  • Live gateway behaviourNo test accessNot tested
  • Tone of the error copyNeeds a personNot tested

Rollback rule agreed before release: pause the branch if duplicate charges appear.

A failure blocks release. Not tested is never reported as passed.

Gate 4Brand approver signs one exact release candidate.Sign RC-1WaitingSigned

Result

Judge the result against a frozen baseline.

After release, the Monitor measures against a frozen baseline. The verdict: keep, tune or roll back.

WI-014MonitorOutcome

Monitor · WI-014MeasuringVerdict · Keep
  • Release matches the approved specCode
  • Unplanned changesCode
  • Result against the frozen baselineCode
Baseline, frozenResultShape only. No values: an illustration of baseline against result, not a measurement.
KeepThe result holds against the baseline.
TuneIt helps, but a threshold or a rule needs adjusting.
Roll backIt hurt a guardrail or changed something unplanned.

The verdict and its reason go back to the Brain. An inconclusive result is reported as inconclusive.

Outcome reviewPM and analytics owner review the verdict.Not sentWaiting for review

Brain log

Replay every decision from the Brain log.

Every approval and send-back is stored with its reason and its approver.

WI-014BrainDecision log

Brain · decision log · WI-014LogReplayed

  1. Gate 1Brand PMApproved

    Real, and worth fixing.

  2. Gate 2PM and leadsPicked: configure the rule

    The cheapest path that reuses what exists.

  3. Gate 3PM, designer, engineerSent back one step

    The error state is missing for bank-side failures.

  4. Gate 3PM, designer, engineerApproved the pack

    Error state added and re-checked.

  5. Gate 4Brand approverSigned RC-1

    One exact release candidate.

  6. Outcome reviewPM and analytics ownerReview the verdict

    Pending the agreed outcome window.

Every approval, send-back and reason is stored. The next audit starts from what worked.

Try it

Try a sample approval flow without changing real systems.

Approve or send back a simulated work item and see the example decision log respond. Decisions stay inside this interactive demo; they are not persisted to a client system.

  1. DetectCode
  2. AuditAgent
  3. Gate 1 · ProblemPersonNever skipped
  4. DecideAgent
  5. Gate 2 · DirectionPerson
  6. BuildAgent
  7. Gate 3 · Design and PRDPerson
  8. ReleasePersonAgent
  9. Gate 4 · ReleasePersonNever skipped
  10. MeasureCode
  11. Outcome reviewPerson

Next · Detect

Detectors

Produces: Signal: data captured that no decision reads

Make your next decision evidence-backed.

Track A can deliver a scoped commercial audit and prioritized recommendations. Track B adds focused intelligence or review where appropriate. ROQIVA illustrates our longer-term product vision.

Book a working sessionCompare the tracks