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.
How it works
Connect signals to better decisions and outcomes.
Our method connects diagnosis, prioritization, solution design, delivery and measurement. See the full six-step orchestration workflow being developed for ROQIVA, and how today’s consulting and modular offerings use it.
The steps
Step through the workflow, one stage at a time.
Explore the reference workflow for ROQIVA. Individual Track A and B engagements cover the stages agreed in scope, without requiring the full platform.
Detectors logScanning4 gaps
Detectors · Pack 1 · run on exportsCode
payments.failure_codePaymentsCRM retry ruleGaporders.statusOrdersCustomer messagesReadsearch.zero_result_termSearch logRange planningGapcustomer.idAppCRM audiencesReadstorefront.notify_meStorefrontRestock messagesGaporders.courier_delayOrdersCustomer messagesGap
4 of 6 signals have no decision that reads them. Code matched every signal to the decision that reads it. No agent is involved.
No gateCode matched every signal. No one needs to approve a log entry.Not neededLogged
Findings inboxRanking6 ranked
F-001Failed payments get one retryPayments → CRM retry rule9F-002Zero-result searches never reviewedSearch log → range planning3F-004Courier delay events unusedOrders → customer messages3F-003Notify-me sign-ups never readStorefront → restock messages2F-006City stock shown as one national totalInventory → product page1.5F-005COD rule with no refusal historyOrders → COD eligibility1
Score = value × confidence ÷ effort. Sample values, not measurements.
Gate 1Brand PM confirms the problem is real and worth fixing.ApproveWaitingApproved
Solutions for WI-014Drafting3 solutions
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.mdEmptyWritingDraft v1RevisingDraft v2
Retry failed payments by failure type
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. ChangedYour 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 startsretry_resultA retry endsfailure_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
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
Monitor · WI-014MeasuringVerdict · Keep
- Release matches the approved specCode
- Unplanned changesCode
- Result against the frozen baselineCode
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
Step 01 of 06
Detect
Detectors match every captured signal to the decision that reads it and flag the gaps. Code does the matching. No agent is involved, and no one needs to approve a log entry.
- Who works
- Detectors
- Produces
- Signal: data captured that no decision reads
- Then
- None, logged
Step 02 of 06
Audit
The Analyst reads the flagged gap, writes what should happen and what does happen, checks the evidence, labels it Confirmed, Supported or Hypothesis, sizes the value as a range and ranks it. Gate 1 opens the work item.
- Who works
- Analyst
- Produces
- Ranked finding cards
- Then
- Gate 1 · Problem. Brand PM confirms the problem is real and worth fixing.
Step 03 of 06
Decide
Research brings outside evidence. Architect checks what can be reused and what could clash. Product drafts two or three solutions with trade-offs, including the cheapest one. They run in parallel, and people choose.
- Who works
- Research, Architect, Product
- Produces
- One chosen product solution, with evidence
- Then
- Gate 2 · Direction. PM and leads pick the solution.
Step 04 of 06
Build
Product writes the requirements and the PRD draft. Design turns them into a reviewable prototype. Architect draws the system design. QA drafts the checks. Gate 3 releases the handoff pack: PRD, wireframe, tickets, test checklist and sources.
- Who works
- Product, Design, Architect, QA
- Produces
- Handoff pack
- Then
- Gate 3 · Design and PRD. PM, designer and engineer approve the pack.
Step 05 of 06
Release
The brand’s engineers build and deploy. The system never writes to their tools. QA reports passed, failed and not tested. The measurement plan is agreed before release.
- Who works
- Brand engineers, QA
- Produces
- Release pack: QA report, checks, rollback rule
- Then
- Gate 4 · Release. Brand approver signs one exact release candidate, and the brand ships.
Step 06 of 06
Measure
The Monitor checks the release against its spec, catches unplanned changes and measures the result against a baseline. The verdict and the reason go back to the Brain.
- Who works
- Monitor
- Produces
- Outcome verdict: keep, tune or roll back
- Then
- Outcome review. PM and analytics owner review the verdict.
The parts
Explore the ROQIVA reference architecture.
Five parts, plus your people and your tools. Each part runs on its own.
Agents never talk to each other. The Orchestrator routes their work and is the only part that writes to the Brain.
- BrainStoreOne versioned model of the brand: tools, rules, design system, decisions, outcomes. Holds context and decides nothing.
- Detectors and AnalystCode and one agentDetectors match every captured signal to the decision that reads it. The Analyst judges, labels and ranks what they find.
- OrchestratorCodeOpens work items, runs agents in parallel, stops at gates and blocks two items touching the same page, event or segment.
- Drafting agentsAgentsResearch, Architect, Product, Design and QA each draft one artifact.
- MonitorCodeChecks releases against their spec, catches unplanned changes and measures results against a baseline.
- PeopleHumansFour gates and one outcome review, each with a named approver.
- Brand tools and engineersExternalThe source of truth. Engineers build and deploy. The system never writes to them.
What it watches
Explore nine commercial problem areas.
MESHHETU investigates gaps across nine commercial areas. The packs below illustrate automated detector coverage and its development status; consulting coverage does not depend on an automated pack being available.
- Pack 1Available today
- Pack 2Planned
- Pack 3Planned
- APack 2
Acquisition and discovery
Ads, catalogue feeds, landing pages, search, attribution tags
ChecksAd price and region match the landing page. Campaign tags reach analytics.
- BPack 1
Account and identity
Sign-up, login, guest-to-user merge, consent
ChecksOne customer key joins app, CRM and orders. Consent flags reach the CRM.
- CPack 1
Shopping and conversion
Search, product page, cart, checkout, payment
ChecksPayment failure reasons are captured. Coupon rules match cart logic.
- DPack 2
Fulfilment
Order routing, delivery promise, RTO
ChecksThe delivery promise shown matches the delivery data customers are sent.
- EPack 2
Post-purchase service
Tickets, refunds, returns, grievance rules
ChecksSupport status reaches the CRM. Customer scores drive grievance and return rules.
- FPack 1
Retention and lifecycle
Reorder, win-back, loyalty, notifications
ChecksUser properties feed audiences. Journeys do not conflict or double-send.
- GPack 3
Channel and partner management
Marketplaces, quick commerce, offline, affiliates
ChecksAffiliate payouts match delivered orders. Price and stock agree across channels.
- HPack 3
Supply, planning and back-office
Inventory, demand, catalogue operations, pricing
ChecksNew SKUs reach marketing. Demand signals reach stock decisions.
- IPack 3
Compliance and trust
Consent, regulatory checks, fraud controls
ChecksConsent is honoured in every sending tool. Gates cannot be bypassed by a flow.
The rules
Hold three rules at every handoff.
01
Code computes
Every count, join and ranking comes from code you can reproduce. No agent computes a number.
Code02
Agents draft
Agents write drafts to a workspace. They never write to a live system, and never approve their own work.
Agent03
People decide
Four gates and one outcome review, each with a named approver. Any gate can send the item back with a reason.
Person
Keep the Brain current and releases honest.
Refresh the Brain only after a person confirms it
Agents never refresh the Brain. A person confirms what each part means before a new version is published.
Watch releases without deploying
The Monitor checks what shipped against what was approved. It never deploys, and it never rolls anything back on its own.
By track
See who runs each stage in each track.
The engineering method is shared; the scope, automation and delivery responsibilities differ across Track A, Track B and developing ROQIVA.
| Stage | Track A · Consulting | Track B · Modular intelligence | Track C · ROQIVA (in development) |
|---|---|---|---|
| Detect | Consulting investigation using approved sources | Scoped analysis at an agreed cadence | Designed detectors and monitoring within the client environment |
| Audit | Consultants verify evidence and findings | Reviewed finding cards based on agreed inputs | Designed Analyst agent |
| Gate 1 | A documented client decision | Client reviews findings in the agreed process | Designed ROQIVA workspace |
| Decide | A founder writes options and strategy, with Research as a tool | The brand’s PM, using the findings | Research, Architect and Product agents |
| Gate 2 | A recorded client call | The brand’s own process | The workspace |
| Build handoff · Gate 3 | PRD, tracking spec, tickets and acceptance criteria. The brand designs and tests | Not included | The pack, with prototype and QA checklist |
| Release · Gate 4 | Client releases; consulting governance if scoped | Client releases; checks only where configured | Designed governed release candidate |
| Measure | Consulting outcome review where scoped | Agreed monitoring and review outputs | Designed outcome workflow |
Start with your actual business problem.
We can scope a consulting investigation or a modular engagement now, and discuss ROQIVA as a future integrated product.