How FactoryOS Builds Charts and Diagrams
Most AI chat answers arrive as a wall of text. You ask about last quarter's numbers and get three paragraphs you now have to turn into a chart yourself.
FactoryOS answers differently. When a visual would say it better, the assistant draws one on a canvas beside the conversation, and it does the drawing on your own hardware.
One Canvas Many Renderers
The canvas is a panel that slides out next to the chat and renders whatever the answer needs. A single asset tool sits in front of several specialized renderers, so the model picks the right one for the job instead of forcing every answer into the same shape.
That choice is deliberate. A dependency map, a revenue trend, and a sortable price list each want a different visual, and one generic chart type would serve all three badly.
It stays part of the conversation, not a separate app. You ask in plain language, and the matching renderer configures itself from what you described.
Charts Tables and Diagrams
Structured answers get a renderer built for their structure. Quantitative data becomes an ECharts bar, line, pie, or scatter plot, while rows and columns become a sortable, filterable DataTables grid for catalogues, comparisons, and result sets.
Relationships get their own tools. Mermaid handles flowcharts and sequence diagrams, ReactFlow lays out node-and-edge pipelines, and Cytoscape maps dense networks and dependencies.
For everything in between there is SVG for free-form infographics and an HTML renderer for dashboards, formatted documents, and even source-code files. The model writes the spec, and the renderer turns it into something you can read.
Images Made on Device
Photographs and illustrations are generated locally too. The image renderer runs Stable Diffusion XL on the same machine, producing concept art, product mockups, scenes, and characters without a round trip to anyone's cloud.
The picture comes back inline, ready on the canvas. Nothing about the prompt or the result is handed to an outside image service.
Nothing Leaves the Building
Every renderer runs on the box you own. The structured visuals are drawn by local libraries from a spec the local model writes, and the images come from a local diffusion model, so no prompt, dataset, or finished asset is shipped to a third party.
This is the part a wrapper around someone else's API cannot promise. For an organization where the data cannot leave the premises, a chart that quietly posts your figures to a cloud service is not an option.
Refine It in Place
A first draft is rarely the last word, so the canvas is built to be revised by conversation. Ask for green bars instead of blue, a tighter date range, or a cleaner layout, and the renderer updates the same asset in place.
You can also flip any asset between its visual form and its underlying source, then hand that source straight into a document or a codebase. Each generation is kept, so the canvas holds a history rather than overwriting what came before.
Visuals Wait Their Turn
A drawn answer is still a model call, so it rides the same GPU queue as everything else. A quick chart returns almost immediately, and a detailed image takes a few seconds while the GPU works through its turn.
What never happens is a surprise. There is no metered image API in the loop and no per-render bill, only the local hardware doing local work.
Why Local Visuals Matter
A visual is often the fastest way to be understood, and the honest ones are drawn from the same data the rest of the system already trusts, the retrieval stack that found the right context in the first place.
Keeping that last step on-premise means the picture is as private as the numbers behind it. When your AI hands you a chart, do you actually know where your data went to draw it?