Identity and permission
The client name is used only with explicit approval. Otherwise the organisation and identifying details remain undisclosed.
DELIVERY EVIDENCE
Evidence before outcomes
A case study should make a result easier to verify, not merely easier to market. This page explains what Clarvia requires before a client identity or performance number is published.
Current evidence status
Clarvia does not currently publish named client results on this page because the supporting permissions and evidence are not present in the materials used to publish it. Previous unsupported entries have been removed. The workflow examples below are illustrative blueprints, not claims of completed client work.
PUBLICATION STANDARD
What a defensible case study contains
Results are useful only when the reader can see what was measured, how it was measured, and what could make the result change. Each future Clarvia case study must satisfy all six requirements.
Baseline definition
The original metric, owner, measurement period, sample size, exclusions, and data source are recorded before comparison.
Intervention record
The workflow change, systems, model or rules version, human-review boundary, and evaluation date are documented.
Outcome evidence
Published numbers trace to logs, reports, analytics, or an attributable client confirmation—not recollection or generated copy.
Reliability context
Success rates appear with errors, exceptions, unsafe-action tests, recovery behaviour, and the operating conditions measured.
Limitations and review
The case study states what was not tested, what cannot be generalised, and when the evidence was last reviewed.
ILLUSTRATIVE — NOT CLIENT CASE STUDIES
Reference workflow blueprints
These examples show the controls and measurements a delivery plan can contain. They do not identify a customer, assert that Clarvia deployed the workflow, or attach a performance result.
Invoice intake and approval
A reference design for extracting invoice fields, validating them against policy, and routing exceptions to a reviewer.
Example controls
- Schema validation before posting
- Duplicate and supplier checks
- Human review for material exceptions
Measures to define
Field-level accuracyException recallCycle timeAudit-log completeness
Shared-inbox triage
A reference design for classifying incoming requests, drafting responses, and assigning work without silent autonomous sending.
Example controls
- Permission-aware retrieval
- Confidence-based review queue
- No-send mode during evaluation
Measures to define
Routing accuracyEscalation recallUnsupported-claim rateTime to assignment
Reconciliation assistant
A reference design for proposing matches, exposing the supporting evidence, and keeping financial approval with an accountable person.
Example controls
- Deterministic amount and date checks
- Evidence attached to each proposed match
- Idempotent retry and rollback tests
Measures to define
Match precision and recallFalse-positive severityRecovery rateReviewer handling time
A reproducible evaluation record
The process is intentionally compatible with the Back-Office Automation Reliability Index v0.1 methodology.
- 1Freeze the workflow, system version, prompts or rules, integrations, thresholds, and evaluation set.
- 2Create ground truth with a named reviewer and record disagreements, exclusions, and critical exceptions.
- 3Run ordinary, edge, adversarial, and dependency-failure cases; retain raw outcomes rather than only the aggregate.
- 4Publish the formula, numerator, denominator, sample composition, limitations, and evidence date beside every result.
Use the open v0.1 scorecard
Ten weighted reliability dimensions, explicit scoring anchors, hard safety gates, and downloadable JSON and Markdown methodology files—with no fabricated benchmark results.