ProvenMap
Platform Features

Archetypes

An archetype is the type of a board element: "API Gateway", "PostgreSQL Database", or "Message Queue". It stores styling, structure rules, and standards. Nodes & Edges covers how elements use archetypes; this page covers the library.

Why archetypes matter

Archetypes replace informal convention with:

  • Consistency: every "Service" looks and behaves the same on every board.
  • Structure: containment rules decide what can nest inside what, so the graph stays valid.
  • Governance: standards and context tags make a diagram queryable.
  • Grounding: plugins and chat reference your catalogue, so a generated element uses a type you defined rather than one a model invented.

The catalogue screen

Open Settings → Element Archetypes. The screen has Catalogue, a searchable grid of archetypes, and Proposals, the review queue for plugin-suggested types.

Actions above the grid:

  • Create Archetype opens the form for one of your own.
  • Load Default Archetypes pulls the shipped library into an empty catalogue, so you start with types rather than a blank page.
  • Sync Defaults brings your catalogue up to date with the current shipped library. Read the rollout caveat below before you press it.
Browse, filter, and manage the element library your whole org draws from.
  1. 1

    Sync Defaults

    Brings your catalogue up to date with the current shipped library. Read the rollout caveat first.

  2. 2

    Create Archetype

    Opens the form for a type of your own when nothing shipped fits your systems.

  3. 3

    Filter down to what you need

    Stack and element-type filters cut 262 archetypes to the 27 that matter right now.

Archetypes you create belong to your org. Shipped ones are shared and read-only. Editing one is copy-on-write: your org gets a copy and the shared original stays unchanged. Delete only touches org-owned types.

Tip

Start with a handful of archetypes that match how your team already talks about the system. Over-configuring on day one usually leaves much of the catalogue unused or slightly wrong.

Anatomy of an archetype

The form has four tabs.

Basic Info is identity: name, slug, description, and default tags. Nodes and plugins reference archetypes by name.

Fields is expected metadata, such as engine on a Database or runtime on a Function, composed from reusable field templates.

Styles controls shape, size, fill, and, for edges, connection shape and markers. Live Preview renders the element as you change it. Colour lives here too.

Advanced is governance: containment rules and standards that plugins and chat follow when generating this type.

Containment is nesting within one board. It differs from layers, where a node links to a separate board. A system can use both.

Colour is a token pair

Fill and stroke are {colour family, weight} pairs, not free-form hex values. Families are shared by related archetypes, and weights render consistently across OKLCH-generated ramps.

Choose colour from a swatch grid in the Styles tab while Live Preview renders the result. There is no hex input, so colour keeps shared meaning.

Pick a family and a weight; the Live Preview shows the element you're actually going to get.

Every canvas colour resolves through one shared ramp, so the picker, preview, and board stay aligned. There is no colour legend because a family means one thing everywhere.

Rolling a colour change out

Updating the shipped colour system takes two manual steps.

  1. Sync Defaults updates your org's catalogue with the current shipped archetypes: new families, new weights, and new types. Anything drawn after this uses the new colours.
  2. A separate resync has to be run by hand against the deployment to repaint the nodes and edges already sitting on existing boards. Until someone runs it, your existing boards keep exactly the colours they have.
Warning

That second step repaints elements from their archetype, which means it overwrites styling anyone customized by hand on an individual element. It defaults to a dry run for that reason. Review what it intends to change before applying it, and tell the people whose boards it touches.

A workspace seeded earlier will not show the current colour system just because the platform updated.

Proposals

You do not have to anticipate every type. /analyze-archetypes scans for missing component patterns and submits proposals instead of inventing types silently. Admins review them in Proposals.

Admins settle the vocabulary before a full analysis runs against it.
  1. 1

    The pending review queue

    Types the plugin found no match for, waiting on an admin rather than invented silently.

  2. 2

    Where each proposal came from

    NEW says the catalogue has no such type; CODE says a code plugin raised it; PENDING says nobody has ruled yet.

  3. 3

    Approve & merge, or reject

    Approving adds the type to the catalogue; rejecting dismisses it with notes back to the plugin.

Proposal kinds:

  • New: a type the catalogue is missing. Approve it and you get an org-scoped archetype you can refine like any other.
  • Improvement: a change to a type you already have. A rename or description update applies on approval. A split or merge is handled by hand because those changes reassign existing nodes between types.

Rejecting keeps your note. Either way, the plugin gets a settled vocabulary before full /analyze.

Where else archetypes turn up

  • Nodes & Edges — the element taxonomy archetypes type, and what colour means once it's on the canvas.
  • Organization Settings — the sibling org-level libraries: context tags, field templates, icons.
  • The Boards API — how a plugin fetches the archetype names it's allowed to push against.

What's next

Nodes & Edges

The building blocks archetypes give a type to.

The Code Plugin

/analyze-archetypes — where proposals come from, and why they come first.

Boards Guide

Placing archetypes on a canvas, click by click.

For Every Role

Governing a landscape with archetypes and tags.