Canvas

Canvas

FigJam, in code — a whiteboard authored as a superlore-canvas spec, auto-designed and auto-laid-out.

The Canvas turns a structured superlore-canvas spec into a polished, interactive whiteboard — no colors, sizes, or positions to choose. You declare what (nodes, edges, groups, intents); superlore auto-designs and auto-lays-out the how. The same spec is the node/edge graph an agent reads over the MCP. Hit the maximize button (top-right) to open any board full-screen.

Edit it like a whiteboard

Every board has an Edit button (the pencil, top-right). Click it and the canvas becomes a FigJam-style editor: drag nodes to rearrange, + Note to drop a sticky, click a node to rename or delete it. Then hit Copy spec — and you get the edited board back as a superlore-canvas JSON (a manual layout with exact coordinates).

That's the whole point: you edit like a whiteboard, but it stays your typed graph — the same structure the MCP serves to agents. No exporting a picture, no drift. Paste the copied spec back into your .mdx and the board reopens exactly as you arranged it.

Shape library

The full FigJam shape vocabulary — basic polygons, arrows, and flowchart shapes — all rendered from the same superlore-canvas spec, auto-designed (token-driven fills, theme-aware) and labeled. Pick a kind, add a label, optionally an intent; superlore does the rest.

Loading canvas…

Sketch an architecture

Frames, services, datastores, and an object store — colorful, auto-placed, all on-brand:

Loading canvas…

Looks great with zero styling

Every node here declares only a kind, a label, and a groupno colours, no sizes, no positions, no intent. superlore's auto-designer does the rest: harmonious hues, soft section fills, tidy ELK layout, crisp connectors. This is the bar — a naive board still reads as a designed FigJam board.

Loading canvas…

Sections within sections

Frames nest: give a group a parent and it sits inside the other section, with a slightly stronger fill so the depth reads at a glance.

Loading canvas…

Not every board is one flow — layouts

A real whiteboard is rarely a single connected diagram. Beyond the layered auto layout, two layouts handle boards that are disconnected:

  • board — a poster of independent sections. Each section is laid out on its own, then the sections are packed in the order you declare them, wrapping into rows. No edges required between them; reorder the spec and the poster re-flows.
  • manual — absolute placement. Every x/y (and a frame's width/height) is honoured verbatim, FigJam-style — for a hand-arranged board reproduced pixel-for-pixel.

Connectors can also carry colour: add intent to an edge to tint the line and its arrowhead, so a flow can be read by colour (or intent: "neutral" for a strong foreground line). Below, three disconnected sections placed in authored order, with the "happy path" coloured:

Loading canvas…

For full, real-world boards built with these layouts — an agentic pipeline pinned with manual, and a multi-section review poster with board — see Briefs.

Embed images

Drop a screenshot, a logo, or an exported diagram straight onto the board with kind: "image" and a src. It's a real node — humans see the picture, the MCP sees it as media in the graph.

Loading canvas…

Brainstorm freely

Set layout: "free" for an organic, FigJam-style scatter — perfect for ideation. Stickies auto-cycle a harmonious palette so a wall of notes looks designed, not gray.

Loading canvas…

A deployment pipeline

A system view that reads top to bottom: source through CI to the registry, then a gated promotion across environments. Edges are typed (depends-on for the gate, blocks for a guard) so the flow carries meaning, not just arrows — and the agent gets those relations in the graph.

Loading canvas…

An ideation board

A free-form brainstorm — layout: "free", sketch: true for the hand-drawn FigJam feel. Sections gather ideas by theme, stickies hold the raw thoughts, and an annotation parks a caveat in the margin. This is the "wall of notes" mode: declare the ideas, get a designed board.

Loading canvas…

A decision & trade-off flow

A weigh-the-options board — the question, the candidate approaches as cards, the criteria they're judged against, the decision diamond, and the outcome. Use this to make a build-vs-buy or which-datastore call legible: the agent reads the options and the chosen edge, not a screenshot.

Loading canvas…

Authoring

A Canvas is a JSON superlore-canvas spec — nodes, optional edges, optional groups. Each node takes an id, a kind (rect · rounded · card · circle · ellipse · diamond · pill · sticky · note · cylinder · icon · image · annotation, plus the FigJam shapes triangle · triangle-down · pentagon · hexagon · octagon · star · cross · arrow-left · arrow-right · chevron · parallelogram · trapezoid · callout · document · process), a label/body, and an optional intent — semantic (accent · success · warning · danger) or a FigJam colour (gray · red · orange · yellow · green · teal · blue · purple · pink). Connect with edges (from/to, optional label, kind, typed rel) or the inline to: sugar. Need precise control? Add x/y/width/height to any node and it's placed exactly there.

The agent-native way to author one is a fenced superlore-canvas JSON block — drop it in any .mdx and it becomes a live board:

Loading canvas…

The knowledge face

The spec is the knowledge graph. An agent calling get_component_data gets exactly the nodes and edges — typed relations included — never a picture:

{
  "kind": "diagram",
  "syntax": "canvas",
  "graph": {
    "nodes": [{ "id": "pg", "label": "Postgres", "kind": "cylinder" }],
    "edges": [{ "from": "api", "to": "pg", "rel": "related" }]
  }
}

A worked board — cutting checkout p99 latency

A real brainstorm, in code. We set sketch: true for the hand-drawn FigJam feel — connectors waver like a marker, section titles + edge labels are handwritten, and each section gets a dotted ground. The board walks left to right: the symptoms we measured, where we looked, the root cause, the options we weighed, the decision, and the rollout plan.

Loading canvas…

A full root-cause board

The same vocabulary scales to a complete incident write-up. This board reads top to bottom across five framed phases — symptoms, the compounding root causes, the app-side fix, the database-side optimization, and the measured impact — using cards for findings, a cylinder for the index, an annotation for the gotcha, and pills for the headline numbers. Every edge is typed (blocks, supersedes, depends-on) so the causal chain is data, not arrows.

Loading canvas…

A product roadmap

A planning board, hand-drawn (sketch: true): three "now / next / later" frames of feature cards, a diamond for the gate decision, and annotations parking the open questions in the margin. The flow edges carry the dependency story, so an agent can answer "what blocks the public API?" from the graph alone.

Loading canvas…

On this page

Built withsuperlore