What we have built, and how we prove it.

Two products we engineered and operate, and the standard every client case study will be held to.

Request evidenceSee the evidence standard

Work in production. Checkable today.

Each product in the four records a client case study uses. Results state only public status and scope.

WR-01 Live

Ravius

Challenge
Leaders make structural decisions about teams on anecdote and lagging reports.
Decision
Put the trust boundaries in the data model, not in a policy on top of it.
System
  • IQ Compass
  • Surveys
  • Feedback
  • Capacity
  • Network
  • Executive brief
Result
Live public product at ravius.com, with six modules and role-based access.Not claimed No usage or outcome figure is published for Ravius.
Product chapter ravius.com(opens in a new tab)
WR-02 Live

VieroMind

Challenge
Mental health support is hardest to reach where stigma, cost and language work together against it.
Decision
Design every sensitive feature from its data boundary outward.
System
  • Assessments
  • Therapist matching
  • Encrypted journal
  • Community
  • Library
  • EN · UR · AR
Result
Live public platform at vieromind.com, run as a nonprofit foundation, in three languages.Not claimed No usage or clinical outcome figure is published for VieroMind.
Product chapter vieromind.com(opens in a new tab)

The evidence so far.

  • 2productsIn production, set out as records you can check
  • 3practicesVerified and checkable on this site today
  • 1claimClient outcomes, held until the clients approve
  • 5fieldsOn every measure: baseline, result, window, scope, source

A case study is an argument about cause and effect. It is only worth reading if the measurement behind it is inspectable.

One standard for every claim we publish.

Client case studies follow a fixed template. The first are in review with the organizations involved.

CS-— · Client case study · templateFirst records in client review
Outcome-led title. Never the client name.
  1. ChallengeThe operational pressure and what inaction was costing.
  2. DecisionThe options considered and the trade-off accepted.
  3. SystemWhat was built, where its boundaries sit, who operates it.
  4. ResultThe measured change, with its baseline and window.
Every measure
  • Baseline
  • Result
  • Window
  • Scope
  • Source
Publication path:
  1. Drafted with the client
  2. In client reviewFirst records here
  3. Measurement approved
  4. Attribution approved
  5. Published

How we publish evidence

  • Every measure states its scope
  • Attribution is approved in writing
  • Nothing is published to fill a layout
  • Technology is metadata

Proof ledger

  • CLM-P01How we startVerified
  • CLM-P02How we buildVerified
  • CLM-P03How we finishVerified
  • CLM-P04Client outcomesPending approval
The full case study record, in reading order
Executive summary
Challenge, Sudens' role, the system delivered and the result — in four records, before any detail.
Context and constraint
Sector, operating scale, and the exact constraints that shaped the work: time, data, security, integration, regulation.
Architecture decisions
Two or three decisions that mattered, the options rejected, and the trade-off accepted in each case.
Delivery and security
How the work was sequenced and verified, and the controls that applied to this specific system.
Results ledger
Baseline, result, measurement window, population and data owner for every measure published.
After launch
What changed in operation, what remained difficult, and what the roadmap did next.
The evidence policy in full
Every measure states its scope
Baseline, result, measurement window, population and data owner are published with the number. A percentage without a window is not evidence.
Attribution is approved in writing
Client names, logos and quotations appear only with recorded permission. Where a client cannot be named, the story still carries sector, organization type, operating scale and the exact constraint.
Nothing is published to fill a layout
Where evidence is not ready, the section says so. We would rather have a shorter site than a persuasive one that cannot be checked.
Technology is metadata
Stacks and tools appear after the business context, because they explain how something was built rather than why it mattered.
Each ledger claim, its scope and where to check it
CLM-P01 · Architecture decisions are written down before implementation begins — including the options we rejected.
Every engagement. Decision records name the trade-off, the constraint that drove it, and the owner.See the Sprint deliverables
CLM-P02 · Security requirements are defined before implementation and verified before release.
Within the agreed system scope of each engagement.Security practice
CLM-P03 · Monitoring, rollback, runbooks and a named ownership model are part of delivery, not a later phase.
Applies to platform, pilot and managed-team engagements.Delivery system
CLM-P04 · Measured client outcomes are published with baseline, result, scope, measurement window and source — or not published.
First case studies are in preparation with the clients involved. Nothing is published before attribution and measurement are approved.How we publish evidence

Why, not just what. Decisions are written down.

Options considered, options rejected, and the trade-off accepted — on every engagement.

  • Context
  • Options considered
  • Trade-off accepted
  • Owner and reviewer
  • Linked commitment

Format illustrativeVieroMind's published commitment. The record layout is illustrative of the format we use.

VM-ADR-004 · VieroMind · Architecture decision recordAcceptedPublished commitment · record format illustrative

Journal entries are never available for model training

Context

The journal is where people write what they would tell no one else. Reflection features need a model to read an entry at the moment of use. Training on entries would improve those features — and would turn the most sensitive data on the platform into a product input.

Options considered
  1. Train on entries from users who opt inRejected
    Consent given in distress is not a reliable basis for reuse.
  2. Train on a de-identified journal corpusRejected
    Free-text journals cannot be dependably de-identified.
  3. Inference-only access, encrypted end to end, nothing retainedChosen
    The feature works; the entry stays the person's.
Trade-off accepted

Reflection quality improves more slowly, from licensed and synthetic data only. In exchange, the platform can state its privacy commitment without qualification.

Owner
Product engineering lead
Reviewed by
Foundation privacy owner
Linked
Privacy-first architecture · User-controlled sharing

Ask for the evidence behind any claim.

We send what can be shared, and say plainly what cannot yet.

  1. 01Product chapters and trust models
  2. 02Security controls, by maturity
  3. 03Architecture Sprint deliverables
  4. 04Delivery system and gates
Or start with an Architecture Sprint

A person replies; it is not a no-reply address.

For example: CTO, Head of Operations, Product Director.

For example: data-handling statement, security questionnaire response, architecture overview, or case evidence for a specific engagement type.

Vendor assessment, procurement stage, security review, or internal approval — and any deadline attached to it.

If a date matters — a board meeting, a launch, a contract.

What you send is used to respond to your inquiry and is shared only with the people reviewing it. Please do not submit production data, credentials, personal data about others, or anything you would not want in an email.