Turn a body of knowledge built over years into a platform that answers, accompanies and shows how the business is running.

The client had content and students; what it lacked was one system of its own holding content, service and growth together. We broke it into brand, then digital infrastructure, then intelligence — four layers: reach (trilingual site, app, mini-programme, channels), platform (courses, commerce, immersive exhibition, member centre), intelligence (answering entry point, AI study companion, omni-channel service desk, natural-language reporting, attribution), and data (unified user ID, operating data base, management dashboard). The hardest part was migrating historic business data off a third-party course SaaS: inventory, interface validation, parallel dual-write, a quiet cutover (about one hour of write downtime) and a rollback path — a commitment of zero data loss and zero business interruption. Only four components are genuinely AI, which we labelled honestly in the documents; the rest is common infrastructure and carries no AI premium.

Turn handbook rules spread across a dozen pages and shared by thirteen programmes into answers that can be cited and audited.

Ten modules: content ingestion and change control, a programme rules layer, cited answering, calibrated routing with a staff console, an embeddable entry point, a model routing abstraction, abuse and cost control, a staff channel, academic-integrity guardrails, and usage analytics. What the client never asked for but we committed to anyway was engineering protection: phase one lands in exam season, and systems like this rarely fail on features; they fail on the first peak month's bill and abuse. Daily and monthly cost gates estimated live on tokens rather than waiting for the cloud invoice, alerting at 80% and degrading rather than shutting off; three-tier rate limiting and anomaly detection; exact plus semantic caching, with rule questions forced through cache — which also satisfies the acceptance clause that the same rule asked ten times must answer the same way.

Before proposing anything, set out that the system is three layers, who owns each, and where safety responsibility sits.

The client wanted a web-based supervisory system to hold temperature and potential across three reactors inside target bands despite varying feedstock, and to accumulate operating experience. After the process interview we submitted an architecture note containing no pricing — because it directly shapes three decisions: how many suppliers to engage, how the contract and acceptance are written, and who carries safety responsibility. We proposed acting as prime contractor (one contract, one point of contact), with our own control and data-acquisition lead owning layers one and two, while stating plainly that the safety instrumented system, fire and chlorine leak detection, and pressure-vessel inspection are outside our scope and must be implemented by licensed parties.

The clinician confirms the plan; MedLoop keeps it running at home and brings back only the exceptions and the results.

Patients scan a code in clinic to bind to the care team and can question a disease-specific AI assistant from the moment they enrol — even before results are back. Once diagnosed, the clinician publishes a personalised care plan across seven dimensions, AI accompanies daily execution, and significant risks return promptly to the clinician's queue. The same flow supports on-time treatment and infection monitoring while accruing prospective research data on different interventions. Patients use a WeChat mini-programme or the app; clinicians use the mini-programme, app or web console.