What it does

The brief was a pharmaceutical intelligence product for Guangdong and Shenzhen, modelled on a reference product the client supplied. I broke it down into nine decision workflows and reviewed nearly 20 of the reference screens for gaps in data access, user needs and the business model.

The product is a native WeChat Mini Program with 27 routes that cover the whole information architecture: search, drug detail, the hospitals that buy a product, hospital procurement catalogues, listings, volume-based purchasing, approvals, consistency evaluation, drugs under review, active ingredients, national and provincial catalogues and market views. Its one stylesheet was ported class for class from the browser demo, so a screen looks the same in both.

There is no sample data in the Mini Program. The corpus is about 22 MB of derived rows, and a Mini Program’s main package is capped at 2 MB, so every screen reads one HTTP API.

How the data works

Behind the screens is a pipeline: manifest, trigger, fetch, raw snapshot, parse, normalise, identity, validate or review, versioned publish, and an API projection for the screens. Each source has a YAML manifest with its access, trigger, fetch mode, parser, identity and validation rules.

Raw files are kept as SHA-256 addressed snapshots, and an ambiguous record goes to a review queue instead of being guessed. An audit checks that the same fact is stated the same way on every screen: a count on the home page equals the real row count of what it names, no price appears without its basis, an agreed purchase volume is never called a purchase volume, and a reference drug is never counted as having passed consistency evaluation.

What I worked on

I worked as an independent AI and strategy consultant for the client, across product, data and engineering: the scope and decision workflows, the Mini Program, the data pipeline and the API, using AI-assisted development.

What has been checked

npm run verify:all checks the screen contracts and everything packed into the Mini Program (no runtime data file, no sample or fixture module), WeChat view-layer assumptions, every source manifest, and the Python pipeline tests: spreadsheet and PDF parsing, normalisation, identity, publishing, pagination, freshness, reconciliation across sources and the screen projections. The case study records 327 tests passing in it. PDF regression fixtures are cut verbatim from the real official documents. Two further checks need the API running: one drives the real page controllers against it, and the audit above.

Five Shenzhen sources have been run against the real official files, with their header aliases and identity keys calibrated on those workbooks. Across the corpus, more than 100,000 records from more than 30 sources are standardised into more than 7,000 searchable drug concepts.

The data also changed the analysis. Testing the client’s market-share premise showed that more than 37,000 hospital–product links covered fewer than 200 generic names, and that Guangdong and Shenzhen data were not directly comparable, so the platform uses separate regional baselines. Backfilling the Guangdong listing series to all 50 batches took it from 2,765 to 8,953 records; together the two platforms hold 27,664 listings.

What remains unproven

These are engineering and data checks. They don’t establish how the client’s users use the product or any business outcome. In the documented setup the Mini Program runs in WeChat DevTools against a locally served API, which is not a public release.

The city data update records the milestone where every remaining city got audited source data with replay. The repository is private; the case study in RIRRI’S shows the Mini Program screens and the proposal.