Viz Platform

A visualization platform I lead. The renderer behind our AI-generated charts and Standard Chart used to be two separate libraries; they now live in one repository. Developers use the chart components directly, while business systems and upstream agents go through one shared protocol.

Illustration, not a product screenshot: three kinds of callers reach one platform that renders financial charts2026

A chart description tied to no engine, usable by business systems and agents alike.

3 paths: ways to use it
2 → 1: libraries merged into one repository
NPM + CDN: standalone components

PROJECT EXAMPLES

Screenshots and examples

Viz Platform consumption paths and execution chain: VizSpec, runtime, provider, viewer — Consumption paths and execution chain
Redrawn from the project documents: developers use components directly, while business systems and upstream agents go through the VizSpec execution chain.

01 / Context

The problem

In the old renderer, protocol, composition, and concrete chart layers were mixed together. A failed validation could still go on to render, and the data cache fingerprinted only sampled values, so a change in the middle of a dataset could go unnoticed. Products also used the chart library directly, so it could not be rewritten from scratch; existing charts, themes, interactions, and lifecycles had to keep working.

What I built

The repository now has the chart and Blocks packages, a compatibility entry for the old interface, several providers, the runtime and viewer, a documentation site, and demo pages. Charts and Blocks work on their own through NPM or a CDN, without AI or a server. Full acceptance of the component documentation and the combined release is not finished, so the platform as a whole is not delivered yet.

02 / System

How the system works

01
Three ways in
Developers use the chart and Blocks components directly. Business systems write a VizSpec for the runtime to execute. Upstream agents go through the planner to produce a VizSpec, then use the same execution chain.
02
Protocol and data
VizSpec is a serializable, engine-independent chart description. Data becomes an immutable snapshot first, and fields, units, duplicate keys, and completeness are checked there once instead of in every layer.
03
Execution and compatibility
The runtime picks a provider from the capability catalog and has no browser dependency; the viewer handles containers, layout, interaction, and lifecycle in the browser. The old execution chain lives in a separate compatibility package that hosts must register explicitly, and the new runtime never imports it.

03 / Decisions

Design choices

The strict entry fails closed

When validation fails, the strict entry stops and returns diagnostics instead of drawing anyway like the old interface. Adapters may not silently change data completeness, units, or versions.

Component libraries stay independent

Charts and Blocks may not depend on the planner, runtime, or any model SDK. A product that only needs a chart installs one component package.

Three states for every capability

Each capability is marked unsupported, candidate, or verified, and an implementation without run evidence is at most a candidate. New capabilities start as a POC or MVP in a separate project and join the platform once they prove workable.

04 / Our work

My role

Role：I set the direction, architecture, and protocol boundaries, and approve changes to task contracts and acceptance criteria. Development runs on the AI workflow I am researching: coding agents claim, implement, and review tasks, and I handle the exceptions the process cannot settle.

01Set the platform positioning, architecture layers, and package dependency directions
02Approve changes to task contracts, protocols, and acceptance criteria
03Decide whether explored capabilities join the platform, and in what order

MonorepoJSON SchemaProvider SDKEChartsNPM / CDN