# How it works — MESHHETU Source: https://meshhetu.com/platform Last updated: 2026-10-16 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. WI-014 · Failed payments get one retry Step 1 of 6 01 Detect Detectors Logged 02 Audit Analyst Gate 1 03 Decide Research, Architect, Product Gate 2 04 Build Product, Design, Architect, QA Gate 3 05 Release Brand engineers, QA Gate 4 06 Measure Monitor Review Signal: data captured that no decision reads 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. Workspace WI-014 Work item WI-014 Failed payments get one retry Step 1 of 6 4 gates Workflow 01 Detect 02 Audit Gate 1 03 Decide Gate 2 04 Build Gate 3 05 Release Gate 4 06 Measure Review Every send-back is stored in the Brain WI-014 Detectors Signals Detectors Code. No agent. Your PM Audit last quarter’s exports. What do we capture that no decision reads? Detectors - Read Payments export - Read CRM retry-rule configuration - Match 6 signals to decisions Code matched every signal to the decision that reads it. No agent is involved. Ask the Analyst Analyst Detectors log Scanning 4 gaps Detectors · Pack 1 · run on exports Code - payments.failure_code PaymentsCRM retry rule Gap - orders.status OrdersCustomer messages Read - search.zero_result_term Search logRange planning Gap - customer.id AppCRM audiences Read - storefront.notify_me StorefrontRestock messages Gap - orders.courier_delay OrdersCustomer messages Gap 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 gate Code matched every signal. No one needs to approve a log entry. Not needed Logged WI-014 Analyst Findings inbox Analyst Audits the exports Your PM Rank the gaps the Detectors flagged. Analyst - Check Evidence for each gap - Rank Value × confidence ÷ effort Ranked the findings. F-001 comes first. Evidence is labelled, and nothing here is a measured result. Your PM Approve F-001. Open the work item. Ask the Analyst Analyst Findings inbox Ranking 6 ranked - F-001 Failed payments get one retry Payments → CRM retry rule Incident Supported 9 - F-002 Zero-result searches never reviewed Search log → range planning Opportunity Supported 3 - F-004 Courier delay events unused Orders → customer messages Incident Confirmed 3 - F-003 Notify-me sign-ups never read Storefront → restock messages Opportunity Hypothesis 2 - F-006 City stock shown as one national total Inventory → product page Incident Supported 1.5 - F-005 COD rule with no refusal history Orders → COD eligibility Opportunity Supported 1 Score = value × confidence ÷ effort. Sample values, not measurements. Gate 1 Brand PM confirms the problem is real and worth fixing. Approve Waiting Approved 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 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 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 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 Step 01 of 06 ### Detect Code 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 Agent 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 Agent 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 Agent 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 Person Agent 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 Code 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. Platform System map Store Brain Tools Rules Design system Decisions Outcomes Code and one agent Detectors and Analyst Match Judge Rank Code Orchestrator Work items Parallel runs Gates Conflict lock Agents Drafting agents Research Architect Product Design QA Humans People 4 gates 1 outcome review External Brand tools and engineers Source of truth Never written to Code Monitor Spec check Unplanned changes Baseline - Brain Store One versioned model of the brand: tools, rules, design system, decisions, outcomes. Holds context and decides nothing. - Detectors and Analyst Code and one agent Detectors match every captured signal to the decision that reads it. The Analyst judges, labels and ranks what they find. - Orchestrator Code Opens work items, runs agents in parallel, stops at gates and blocks two items touching the same page, event or segment. - Drafting agents Agents Research, Architect, Product, Design and QA each draft one artifact. - Monitor Code Checks releases against their spec, catches unplanned changes and measures results against a baseline. - People Humans Four gates and one outcome review, each with a named approver. - Brand tools and engineers External The source of truth. Engineers build and deploy. The system never writes to them. Detectors match every captured signal to the decision that reads it. The Analyst judges, labels and ranks what they find. Opens work items, runs agents in parallel, stops at gates and blocks two items touching the same page, event or segment. Research, Architect, Product, Design and QA each draft one artifact. Four gates and one outcome review, each with a named approver. Checks releases against their spec, catches unplanned changes and measures results against a baseline. Brain One versioned model of the brand: tools, rules, design system, decisions, outcomes. Holds context and decides nothing. One work item travels the ring Every part reads and writes the Brain 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 1 Available today - Pack 2 Planned - Pack 3 Planned A Pack 2 ### Acquisition and discovery Ads, catalogue feeds, landing pages, search, attribution tags Checks Ad price and region match the landing page. Campaign tags reach analytics. B Pack 1 ### Account and identity Sign-up, login, guest-to-user merge, consent Checks One customer key joins app, CRM and orders. Consent flags reach the CRM. C Pack 1 ### Shopping and conversion Search, product page, cart, checkout, payment Checks Payment failure reasons are captured. Coupon rules match cart logic. D Pack 2 ### Fulfilment Order routing, delivery promise, RTO Checks The delivery promise shown matches the delivery data customers are sent. E Pack 2 ### Post-purchase service Tickets, refunds, returns, grievance rules Checks Support status reaches the CRM. Customer scores drive grievance and return rules. F Pack 1 ### Retention and lifecycle Reorder, win-back, loyalty, notifications Checks User properties feed audiences. Journeys do not conflict or double-send. G Pack 3 ### Channel and partner management Marketplaces, quick commerce, offline, affiliates Checks Affiliate payouts match delivered orders. Price and stock agree across channels. H Pack 3 ### Supply, planning and back-office Inventory, demand, catalogue operations, pricing Checks New SKUs reach marketing. Demand signals reach stock decisions. I Pack 3 ### Compliance and trust Consent, regulatory checks, fraud controls Checks Consent is honoured in every sending tool. Gates cannot be bypassed by a flow. The rules ## Hold three rules at every handoff. 1 score = value × confidence ÷ effort 2 F-001: 3 × 3 ÷ 1 = 9 3 # reproducible, no agent computes it 01 ### Code computes Every count, join and ranking comes from code you can reproduce. No agent computes a number. Code PRD.md Draft Writes to the workspace only 02 ### Agents draft Agents write drafts to a workspace. They never write to a live system, and never approve their own work. Agent PM Gate 1 · Brand PM Confirm the problem is real Approved 03 ### 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. - Gate 2 Picked: configure the rule - Gate 3 Sent back one step - Gate 3 Approved the pack ### 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. Keep Tune Roll back ### 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. Who runs each stage, by track 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. [Book a working session](https://meshhetu.com/contact#book) [Meet the six agents](https://meshhetu.com/agents)