Interactive Demo — Synthetic Data

01 — Overview

A recovery programme you can read, gate by gate.

This is a static, read-only walkthrough of the product using the deterministic synthetic tenant ACME Industrial. Every figure, case, invoice and message below is invented demonstration data that ships with the acquisition package — it is reproducible on demand and contains nothing about any real person or company.

$16,500 Recovered revenue 4 cases · evidence-verified
$444,408 Revenue at risk open cases · one exposure per subject
38 Open recovery cases 6 case types
10% Recovery rate recovered ÷ (recovered + open)

Pipeline state

Automation rate: 78% — executed ÷ all actions
Pending human approvals: 3 — sensitive commercial actions
Open escalations: 2 — routed to a person
Influenced revenue: $7,000 — engagement, no payment evidence
Attribution confidence: 72% — average across RECOVERED cases

Synthetic dataset behind these numbers

Tenant: ACME Industrial (fictional)
Customers / leads: 47 / 28
Quotes / invoices: 62 / 54
Promises / disputes: 17 / 6
Control tenant: Northwind Components — used for isolation checks

One deterministic seed builds this tenant, so the same numbers come back every run. Shadow mode is on and no provider credential is configured, which is why nothing can be dispatched even by mistake.

02 — Recovery cases

Six synthetic cases, one at a time.

Pick a case to see what was detected, what the AI proposed, which gates it passed, whether a human has to decide, and what the outcome was. All six types the product supports are here.

QUOTE acme-case-quote-014

Abandoned quote — 1 × Hydraulic Pump

Customer 07 ACME · acme-buyer-07@example.test

$4,200 amount at risk

Problem detected: The quote was sent, then nothing happened for 12 days.
Detected event: quote.sent — no activity afterwards
Detection source: Scheduled sweep over open quotes with no activity for 7 or more days
Risk: LOW
Score: 78 · how urgently the case is worked

Policy engine — ALLOWED

$4,200 sits below the tenant's $5,000 automatic-handling ceiling. This is follow-up 1 of a maximum of 3, and the last contact was 13 days ago (minimum interval 48 hours).

Approval engine — NOT REQUIRED

Nothing commercial is changing: no discount, no price change, no credit, no cancellation.

Recommended action

Send follow-up 1 of 3 — no discount, no price change.

Structured AI decision

Simulated example. The contract has no field for a price, a discount or a payment term — the model cannot invent one.

{
  "caseId": "acme-case-quote-014",
  "caseType": "QUOTE",
  "action": "SEND_FOLLOW_UP",
  "attempt": 1,
  "channel": "EMAIL",
  "recipient": "acme-buyer-07@example.test",
  "rationale": "The quote has remained inactive for 12 days.",
  "confidence": 0.82,
  "requiresApproval": false,
  "risk": "LOW"
}

Gate-by-gate

AI decisionPASSStructured output produced and validated against the decision schema.
ValidationPASSRecipient belongs to the case; the message references catalogue content only.
Policy checkPASSBelow the $5,000 ceiling · attempt 1 of 3 · 13 days since the last contact.
Risk checkPASSLOW — no commercial change, no discount, no legal element.
Approval checkNOT REQUIREDNothing on the human-approval list is involved.
Idempotency checkPASSOne dispatch per attempt — no earlier send for this case and attempt.
ExecutionSIMULATEDShadow mode is on in the demo tenant, so the dispatch is simulated.
Audit logSIMULATEDThe decision, the gates and the outcome are recorded for audit.

Synthetic timeline

Day 0
quote.sent — the customer requested a quote for 1 × Hydraulic Pump at the catalogue list price.
Day 12
Detected — the sweep finds 12 days of inactivity and opens the case.
Day 12
Decision — the AI proposes follow-up 1 of 3; policy, risk and approval gates clear.
Day 12
Action prepared — shadow mode on, nothing is dispatched.
Day 14
Reply received — pending work is cancelled and the case moves to INFLUENCED, pending payment evidence.

Outcome — INFLUENCED

The customer replied two days later. A reply on its own is never recovered revenue, so the case stays INFLUENCED until payment evidence is verified.

JavaScript is switched off, so the six cases cannot be switched above — the first case is shown, and every other section of this page is complete and readable without scripting.

03 — AI decision

The AI proposes. Gates decide. A human approves the sensitive parts.

A worked simulated example, from detection to outcome. The decision is a structured object that has to survive validation, policy, risk, approval and idempotency before anything is executed — and the tenant's policy always wins over the model.

Detection

“The quote has remained inactive for 12 days.”

Decision

“Send a follow-up message.”

Policy

“Allowed — inside the tenant's follow-up budget and value ceiling.”

Risk

“Low — no commercial term is changing.”

Approval

“Not required.”

Action

“Follow-up prepared.”

Outcome

“Customer re-engaged — classified INFLUENCED, not recovered.”

Simulated example. No email, message or provider call is made from this page at any point, and none was made to produce the text above. “Follow-up prepared” means the payload exists inside the system; whether it is ever dispatched is decided by the gates, by the tenant's policy and — for anything commercial — by a person.

Guards applied to every decision

Schema validation — a malformed decision is rejected before it reaches a gate
Grounding on the tenant's own catalogue, knowledge and policy only
Hallucination, price and discount guards on the generated text
Recipient authorisation — the contact must belong to the case
Prompt-injection screening of inbound customer content
Escalation strips the subject, body and recipient before routing to a person

What the model can never do

Invent a price, a discount, a payment term or a product
Decide a commercial outcome — policy overrides the recommendation
Execute anything directly: the model has no path to the connector layer
Approve its own proposal, or bypass the approval gate
Send twice for the same attempt — execution is idempotent

04 — Revenue attribution

A reply is not revenue. Payment evidence is.

Every case ends in one of five states, and only one of them counts as recovered revenue. The amount has to be proven by evidence the system can verify inside the tenant's own data — otherwise it is reported as influenced, organic, unrecovered or simply unknown.

RECOVERED
A conversion plus payment or order evidence inside the attribution window, above the confidence threshold. This is the only state that adds to recovered revenue.
INFLUENCED
The customer engaged after a recovery contact but no payment evidence exists yet. Reported separately and worth nothing as revenue.
ORGANIC
The money arrived with no recovery contact preceding it — the customer would have paid anyway. Never claimed as recovery.
UNRECOVERED
Verified evidence that the customer did not convert — a decline, or a case closed without any conversion evidence.
UNKNOWN
There is not enough verified evidence to classify the outcome. It is not counted as anything, and it is not hidden either.

Evidence chain, and the rules around it

Case → action → external message → customer interaction → quote or order → payment or invoice
RECOVERED needs a conversion, payment or order evidence, contact inside the attribution window (default 30 days) and confidence at or above the threshold (default 0.6)
Evidence is verified against the tenant's own rows before the amount is counted; an unverifiable claim stays recorded but never moves revenue
One current attribution per case, append-only history, deterministic fingerprints so a recomputation can never count the same money twice
A case claim is a ceiling: if the proven amount is smaller — a partial payment, for example — the proven amount is what is reported
Human confirmation is available for evidence, and cross-tenant evidence is rejected

The synthetic tenant's revenue scenarios and the state each one receives. This is demonstration data from the fictional ACME Industrial tenant, not customer outcomes.
Synthetic scenario	What happened (invented)	State	Counted
Quote recovered	Quote followed up, accepted, invoice raised and paid	RECOVERED	$4,000
Invoice recovered	Overdue invoice chased with reminders, then paid	RECOVERED	$8,000
Partial payment	Claim was larger than the payment received	RECOVERED	$2,500
Inflated claim	The case claimed more than the evidence could prove	RECOVERED	$2,000
Acceptance only	The customer accepted, but no payment was ever recorded	INFLUENCED	$0
Paid without contact	The payment arrived with no recovery contact before it	ORGANIC	$0
Reply, no payment	The customer replied and then went quiet	UNKNOWN	$0
Declined quote	The customer declined with verified decline evidence	UNRECOVERED	$0

RECOVERED $16,500
INFLUENCED $7,000
ORGANIC / UNRECOVERED / UNKNOWN $0 counted

05 — Integrations

Where the data comes from — and how honest each level is.

Recovery starts with inbound facts. The connectors below exist in the software; they are driven against local stand-ins that reproduce each provider's real authentication, paging and webhook signature scheme, and none of them has been authenticated against a real account. This demo page is not connected to anything at all.

Implemented · tested
In the software: the recovery engine, policy, risk, approval and attribution modules, covered by the automated suite against real PostgreSQL and Redis.
Framework · foundation
In the software: the connector registry, the Connection API, inbound webhook verification, identity mapping and the governed execution pipeline that every provider plugs into.
Requires buyer credentials
Every external provider. Validating a connector against a real account needs real credentials, which are deliberately not part of the transfer. No connector is live verified.
Synthetic · demo only
This page, the ACME Industrial tenant and the synthetic mailbox, CRM, billing and payment stand-ins. They replace the providers for demonstration and testing only.

The connectors present in the software, with their highest reached verification level. None of them is connected to a real account, here or anywhere in the asset.
Provider	Category	Capabilities	Verification reached
Resend	Email	`EMAIL_SEND`, `EMAIL_WEBHOOKS`	Stand-in verified
Gmail	Email	`EMAIL_SEND`	Stand-in verified
Outlook	Email	`EMAIL_SEND`	Stand-in verified
HubSpot	CRM	`CRM_READ_CUSTOMERS`, `CRM_READ_LEADS`, `CRM_WRITE_ACTIVITY`	Stand-in verified
Stripe	Billing	`BILLING_READ_INVOICES`, `BILLING_READ_PAYMENTS`	Stand-in verified
Shopify	E-commerce	`ECOMMERCE_READ_ORDERS`	Stand-in verified
WooCommerce	E-commerce	`ECOMMERCE_READ_ORDERS`, `ECOMMERCE_WEBHOOKS`	Stand-in verified
Tiendanube / Nuvemshop	E-commerce	`ECOMMERCE_READ_ORDERS`, `ECOMMERCE_WEBHOOKS`	Stand-in verified
Mercado Pago	Payments	`PAYMENTS_READ`, `PAYMENTS_WEBHOOKS`	Stand-in verified
WhatsApp Business (Cloud API)	Messaging	`MESSAGING_WEBHOOKS` (inbound only)	Stand-in verified
Generic REST	Generic	`GENERIC_API_READ`	Stand-in verified
Generic webhook	Generic	`GENERIC_WEBHOOKS`	Stand-in verified
Mock email	Email (test)	`EMAIL_SEND`	Local by design

How inbound data is protected

Provider webhook signatures are verified against the raw request body, per provider
Replay protection: a repeated delivery is acknowledged but never reprocessed
An unknown or unsatisfiable signature scheme is refused rather than accepted
Provider batches are expanded per event instead of being collapsed into one
Credentials are encrypted at rest and refreshed before use; tokens are never logged
Unknown providers fail closed — the registry will not invent a connection

What is not implemented

No scheduled connector synchronisation — reads happen on demand or by manual import
No connector drift monitoring — no background re-verification of accounts
No live provider validation anywhere in the asset
No billing, metering, password-reset transport or CI/CD pipeline

06 — Safety and control

The AI has no hand on the trigger.

A recommendation is not an action. Everything the model produces has to pass the same chain, in the same order, and the sensitive steps stop for a person.

AI decision
Validation
Policy check
Risk check
Approval check
Idempotency check
Execution
Audit log

In this order, every time: AI decision → validation → policy check → risk check → approval check → idempotency check → execution → audit log.

Try a simulated action

Pick something a real deployment might attempt. The gates below are evaluated with the synthetic tenant's policy — nothing is executed, and nothing leaves this page.

Human approval is required for

Discounts and price changes
Contract changes and cancellations
Credits and refunds
Exceptional commercial conditions
Legal actions
Anything that exceeds the tenant's policy limits — the discount in case 6 stops here

Contact safety before any send

Suppression list: unsubscribed, bounced, complained, do-not-contact, inactive
Per-customer cooldown across cases, and a per-case contact budget
Business hours for the sending organisation; out-of-office pauses the chase
Duplicate prevention through idempotency, plus rate limits on outbound traffic
An emergency stop that wins any race, and stale executions that are reconciled instead of retried blindly

This page specifically cannot

Send an email or a message — there is no transport here at all
Call a provider API — the page's policy forbids any outbound network request
Write to a database — there is no database behind this page
Store anything about you — no cookies, no analytics, no tracking
Reach the real product — the demo is a separate static page

Resulting guarantees for a buyer

Read-only: every button here changes only what you see on screen
Deterministic: the synthetic dataset rebuilds to the same figures every run
No credentials anywhere in the page or in the asset
Shadow mode on by default, so a real deployment starts silent
Tenant isolation asserted by the automated suite, not assumed

07 — Acquisition

Interested in the underlying software?

This page is a demonstration of the product's behaviour built on fictional data. The asset itself is the complete, tested software foundation — and it is pre-revenue, with no customers and no live integrations, which the acquisition documentation states plainly.

View acquisition details

The full asset overview, verification evidence, current status and the transfer model are on the acquisition homepage. There is no contact form and no email address on this page; contact happens through the marketplace listing once it is published.

What you have just seen

Six recovery case types with detection, decision and outcome per case
A structured AI decision, and the guards that constrain it
Policy, risk, approval and idempotency gates in the order they run
Evidence-based attribution where only one state counts as revenue
Thirteen connectors, each labelled with its real verification level

What this page is not

Not the product — it is a separate static page with no backend
Not a live integration demo — nothing is connected to any provider
Not customer evidence — ACME Industrial is fictional
Not a claim of revenue, traction, demand or valuation
Not a trial account — there is nothing to sign up for and nothing to unlock