# Example run — MESHHETU Source: https://meshhetu.com/examples Last updated: 2026-10-16 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. Finding card · F-001 Incident lane Failed payments get one retry Payments → CRM retry rule Confirmed Supported Hypothesis Confirmed Code reproduced the counts. Brain · Gate 3 Send-back Sent back one step The error state is missing for bank-side failures. PM, designer, engineer On this page - Signal map - Finding card - Ranking - Solutions - PRD and wireframe - Release and result - Brain log - Gate simulator 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-014 Detectors Signal map Payments payments.failure_code Orders orders.status Orders orders.courier_delay Search log search.zero_result_term App customer.id Storefront storefront.notify_me Decision · reads none of these CRM retry rule Decision Customer messages Decision · reads none of these Range planning Decision CRM audiences Decision · reads none of these Restock messages - payments.failure_code Payments Captured, never read by CRM retry rule. - orders.status Orders Read by Customer messages. - orders.courier_delay Orders Captured, never read by Customer messages. - search.zero_result_term Search log Captured, never read by Range planning. - customer.id App Read by CRM audiences. - storefront.notify_me Storefront Captured, never read by Restock messages. 6 of 6 matched · 2 read · 4 gaps Read by a decision Captured, 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 Expected What should happen A payment failure reason changes how the failure is retried. Observed What actually happens Gateway failure codes are captured on every attempt, but the CRM retry rule treats hard, transient and bank-side failures the same. Sources Where the evidence comes from Payments export. CRM retry-rule configuration. Evidence label How proven it is Supported The evidence is consistent, but the counts are not yet reproduced. Value range What 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 owner What it costs and who must act An engineering estimate, and the team that owns the retry rule. Not seen What the Analyst could not inspect Card-network decline reasons were not in the export. Unseen is never reported as healthy. Try each label Confirmed Supported Hypothesis 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 F-001 Failed payments get one retry Payments → CRM retry rule Value 3 × Confidence 3 ÷ Effort 1 9.0 - 2 F-004 Courier delay events unused Orders → customer messages Value 2 × Confidence 3 ÷ Effort 2 3.0 - 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 F-002 Zero-result searches never reviewed Search log → range planning Value 3 × Confidence 2 ÷ Effort 2 3.0 - 2 F-003 Notify-me sign-ups never read Storefront → restock messages Value 2 × Confidence 1 ÷ Effort 1 2.0 - 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-014 Product agent Solutions Product agent Drafts the solutions Your PM Draft solutions for F-001. Include the cheapest. Product agent - Research Outside evidence - Architect What to reuse, what could clash - Product Draft two or three solutions Product agent Three solutions with trade-offs. The cheapest is first. People choose at Gate 2. Your PM Go with the first one. Ask the Product agent Product agent Solutions for WI-014 Drafting 3 solutions A Configure Cheapest #### 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. B Build #### Build a dedicated retry service + Full control over timing and channels. − The longest path to ship. C Run 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 2 PM and leads pick the solution. Pick A Waiting Picked 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-014 Product agent PRD.md Product agent Drafts from the Brain Your PM Turn the Gate 2 decision into a spec our engineers can build. Product agent - Read Finding F-001 - Read Gate 2 decision - Read Order events - Write PRD.md Product agent Wrote PRD v1: four requirements, three events and three acceptance checks. It is a draft until Gate 3. Finding F-001 Gate 2 decision Your PM R2 Why never retry a hard decline? Product agent - Read Payments export - Read CRM retry rule A hard decline is a final refusal from the bank, so a retry rarely changes the result and can look like a second charge attempt. This rests on the failure codes in the export, not on a measured retry result. Supported Payments export CRM retry rule Unseen Card-network decline reasons were not in the export. Your PM Comment on R3 Bank-side failures have no error state. Add one. Product agent - Read Comment on R3 - Edit R3 and the Error state Added bank-side failures to R3 and to the Error state in the wireframe. Linked to the Gate 2 decision. Ask the Product agent Product agent PRD.md Empty Writing Draft v1 Revising Draft v2 ### Retry failed payments by failure type Owner · Your PM WI-014 Gate 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 - R1 Capture the failure class on every failed payment attempt. - R2 Retry transient failures once, after a short delay. Never retry a hard decline. - R3 Show 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 PM Comment Resolved Bank-side failures have no error state. Add one. Comment - R4 Send 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_attempted A retry starts - retry_result A retry ends - failure_class On 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 3 PM, designer and engineer review the pack. Not sent Waiting for review Release ## Verify the release before it ships. A failed check blocks release. WI-014 QA agent RC-1 QA agent Checks the build Your PM Run the checks on RC-1. QA agent - Run Checks from the pack - Write QA report QA agent One check failed, and a failure blocks release. Two were not tested, and they are not reported as passed. Brand engineer Fixed the error screen. Please re-check it. QA agent - Re-run Screen matches the wireframe Passed. The two untested checks still need a person or test access. Ask the QA agent QA agent QA report · RC-1 Running Blocked Checked 2 passed · 1 failed · 2 not tested 3 passed · 0 failed · 2 not tested Release blocked Ready to sign - Tracked events fire on retry Passed - Failure path completes Passed - Screen matches the wireframe Failed Passed - Live gateway behaviour No test access Not tested - Tone of the error copy Needs a person Not 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 4 Brand approver signs one exact release candidate. Sign RC-1 Waiting Signed 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-014 Monitor Outcome Monitor Code. No agent. Monitor - Check Release matches the approved spec - Check Unplanned changes - Compare Result against the frozen baseline Monitor The result holds against the baseline, so the verdict is Keep. The verdict and its reason go to the Brain. Monitor · WI-014 Measuring Verdict · Keep - Release matches the approved spec Code - Unplanned changes Code - Result against the frozen baseline Code Baseline, frozen Result Shape only. No values: an illustration of baseline against result, not a measurement. Keep The result holds against the baseline. Tune It helps, but a threshold or a rule needs adjusting. Roll back It 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 review PM and analytics owner review the verdict. Not sent Waiting 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-014 Brain Decision log Brain Decision log Your PM Why was the pack sent back at Gate 3? Brain - Read Decision log · WI-014 Brain The error state was missing for bank-side failures. Gate 3 sent the pack back one step, the state was added and re-checked, and the pack was then approved. Ask the Brain Brain Brain · decision log · WI-014 Log Replayed Gate 1 Brand PM Approved Real, and worth fixing. Gate 2 PM and leads Picked: configure the rule The cheapest path that reuses what exists. Gate 3 PM, designer, engineer Sent back one step The error state is missing for bank-side failures. Gate 3 PM, designer, engineer Approved the pack Error state added and re-checked. Gate 4 Brand approver Signed RC-1 One exact release candidate. Outcome review PM and analytics owner Review 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. - Detect Code - Audit Agent - Gate 1 · Problem Person Never skipped - Decide Agent - Gate 2 · Direction Person - Build Agent - Gate 3 · Design and PRD Person - Release Person Agent - Gate 4 · Release Person Never skipped - Measure Code - Outcome review Person Next · Detect Detectors Produces: Signal: data captured that no decision reads Run Detect Merge Gates 2 and 3 for a small change Gates 1 and 4 can never be merged or skipped. Brain log Nothing recorded yet. Run the first step. ## 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 session](https://meshhetu.com/contact#book) [Compare the tracks](https://meshhetu.com/services)