Delivery case
It has a describable delivery scope, public or anonymized permission, outcome evidence, and a review owner. Only work that meets this threshold uses this label.
Selected work
See how we break down a problem before deciding how to deliver.
This page collects approved delivery cases, research, and proposals. Each page explains what it is and is not; simulated data is not written as an outcome, and research estimates are not presented as client endorsement.
Evidence levels
State the evidence clearly before discussing results.
A corporate website loses trust not because it lacks polished cases, but because it mixes research, proposals, illustrations, and real delivery. ZhenheAI labels every public item with its content type, scope, limits, owner, and last review date.
Research
Show the problem, data, method, and decision output; research estimates do not mean a client achieved the same result and are not a product promise.
Proposal
Show how a complex need becomes scope, assumptions, risks, and next steps; a proposal is not a completed project outcome.
Verified delivery record
One example: this website migration.
This is a ZhenheAI-owned delivery record, not a customer result. It documents the move from Astro/Cloudflare to Odoo Online, the corporate-first content model, CRM intake, and the evidence limits that remain visible after launch.
Read the delivery casePublication gate
Before publication, a case must answer at least five questions.
What was the problem?
It describes the concrete conditions before the work began instead of using a generic phrase such as “digital transformation.”
What did we deliver?
It distinguishes the actual scope of research, design, website, integration, workflow, or automation.
How do we know the result?
It has a metric source, or clearly identifies a validated qualitative result and its limits.
Who can review it?
It has a content owner, permission or anonymization status, and a last review date.
The public material is still being organized into evidence. For now, this page establishes transparent categories and publication standards instead of packaging unapproved proposals as client outcomes.
Discuss a similar problem
You do not need a perfect case before you can start improving a workflow.
If you want to unpack a real workflow, we can start with the current state, constraints, and observable result.
Discuss a similar problem