Public proof-of-value examples — synthetic, never live proof
Static examples explain familiar workflow failures. The executable Synthetic Assurance Lab goes further: it runs real deterministic FlowSentinel derivations against a separate synthetic trust domain and explicitly shows what the scenario proves, what remains unknown, and which authority leaps are forbidden.
Start here: synthetic means synthetic
These pages do not inspect your real workflows, call providers, use customer data, count toward workspace readiness, promote provider maturity, append production Witness history, or authorize recovery/production changes.
Observed evidence · synthetic scenario
Missing proof
Inferred risk · scenario hypothesis
Exact next action · bounded
Synthetic Assurance Lab
Ten deterministic cross-feature case studies reuse the production Assurance Twin, proof-frontier, exact blast-radius, recovery-lifecycle/currentness, and maturity-firewall engines. Each case has a reproducible SHA-256 scenario root, a Minimal Proof Plan, explicit forbidden authority moves, and a hard guarantee that synthetic success cannot become live evidence.
One fact changes. The exact claim must follow.
Eight falsification cases mutate one named fact in a synthetic evidence chain, rerun the production derivations, and compare exact before/after signals. They check both expected degradation and neighboring claims that must remain stable—without creating a global trust score or any live authority.
Pick a failure shape and read the proof loop.
This stays on simulated data. Choose the pain that looks familiar, then inspect the observed evidence, missing proof, and exact next action.
Simulated scenario
Lead routing failure
Form or lead source captures a new inquiry, then the automation should create a CRM record and notify Slack or email.
Observed evidence
Lead captured at the source with timestamp, source name, and expected downstream handoff.
Missing proof
No CRM record ID, Slack message, or email delivery evidence is attached to the lead handoff.
Exact next action
Open the provider run for this lead, inspect the CRM create step first, then rerun or repair the notification branch and attach the resulting record/message proof.
What breaks
The lead was captured, but CRM creation and notification proof are missing.
What FlowSentinel sees
A source event exists, the downstream CRM/notification boundary has no matching observed proof, and the workflow should not be treated as recovered yet.
Inferred risk
A sales follow-up may be delayed because the lead could be trapped before the CRM or notification step.
Recovery proof packet example
A presentation-only sample that demonstrates how a report can separate scenario-grounded claims, unresolved proof, and the next verification action. It is explicitly not a live customer proof packet.
Lead routing failure
- What breaks
- The lead was captured, but CRM creation and notification proof are missing.
- Why it matters · Scenario risk hypothesis
- A sales follow-up may be delayed because the lead could be trapped before the CRM or notification step.
- What FlowSentinel shows · synthetic scenario
- Observed source event is available; CRM and notification proof are missing.
Client onboarding failure
- What breaks
- The customer signs up, but the downstream onboarding step remains unproven.
- Why it matters · Scenario risk hypothesis
- A new customer may be waiting without internal setup, files, or first instructions.
- What FlowSentinel shows · synthetic scenario
- Observed signup/payment evidence exists; task/folder/email proof is missing.
Support escalation failure
- What breaks
- A high-priority issue exists, but escalation proof is missing.
- Why it matters · Scenario risk hypothesis
- A time-sensitive customer issue may sit in the queue without alerting the responsible operator.
- What FlowSentinel shows · synthetic scenario
- Ticket priority is observed; routing proof and acknowledgement are missing.
Billing/CRM sync failure
- What breaks
- The payment event exists, but CRM or accounting sync is stale or missing.
- Why it matters · Scenario risk hypothesis
- Customer access, renewal follow-up, or finance reporting may be wrong because business systems disagree.
- What FlowSentinel shows · synthetic scenario
- Payment event is observed; CRM/accounting update proof is absent or older.
Daily report stale-data failure
- What breaks
- The report ran, but data freshness or delivery proof is missing.
- Why it matters · Scenario risk hypothesis
- Operators may be reading yesterday's numbers while assuming the report is current.
- What FlowSentinel shows · synthetic scenario
- Scheduler event exists; data refresh and final delivery evidence are absent.
Webhook/retry failure
- What breaks
- The webhook was received, but the transformed destination write is not verified.
- Why it matters · Scenario risk hypothesis
- The source system thinks delivery started while the destination may never receive the usable record.
- What FlowSentinel shows · synthetic scenario
- Inbound event exists; destination acknowledgement and retry proof are missing.
Technical demo workflow asset packs are tracked in repo docs at docs/demo-workflows. They remain optional reference material for synthetic scenarios, not live provider evidence.