Save and refer to baselines.

A baseline is a named, immutable snapshot of the model at a moment in time. Use one when you reach a milestone you want to refer back to — Phase 1 sign-off, the v2.3 release, the architecture as it stood when you handed it to procurement. The current model keeps moving; the baseline doesn't.

What baselines are good for

• Marking sign-offs: a baseline is a stable reference you can point at in an email, a wiki page, or an audit response months later — "the architecture as approved on 12 March".
• Versioning without branching: HEAD evolves. Baselines pin specific states without forking the model into separate copies that have to be reconciled.
• Honest cross-document references: when an ADR or a design review document quotes the model, it cites a baseline so the reader knows exactly what shape the model was in when the document was written.

What baselines are not at v1.0

The current scope is intentionally narrow. Three things you might expect but won't find yet:

• No restore. A baseline is a reference; you can't overwrite the current model with it. If you want the current model to look like the baseline, the path today is to read the baseline (server-side) and reproduce the changes by hand.
• No diff. "What changed since Phase 1 sign-off?" isn't a built-in view. Each baseline is a complete document, so an external diff tool works if you really need it.
• No snapshot-bound exports. Every export (SVG, PNG, PDF, XMI) is from HEAD. Exporting a frozen baseline is on the post-launch list.

If any of these is a launch blocker for the way you work, say so — the deferrals are timing, not principle.

Before you start

• A model open in the editor.
• Editor access or better. Viewer-role teammates see existing baselines but can't create or delete them.

Step 1 — Find the Baselines tab

1. Open the editor for the model you want to baseline.
2. In the package explorer on the left, click the model node (the top of the tree, named for the model).
3. The right-hand property panel shows three tabs: Properties, Metadata, Baselines.
4. Switch to Baselines.

Step 2 — Save a baseline

1. Type a label that names what's being marked: Phase 1 sign-off, v2.3 baseline, Pre-cloud-migration. Up to 120 characters.
2. Click Save.

The baseline appears in the list below the form with its label, the date it was taken, and its size. The current model keeps editing from where it was; the baseline holds its state.

Step 3 — Refer to a baseline

On every baseline row there's a Copy ref button. It writes a structured reference to your clipboard, ready to paste into a document, an email, or a chat:

Phase 1 sign-off · model my-platform · baseline 04e512d9-6d34-41b5-8a35-940198fe487f · 30 May 2026

The reference is human-readable but carries the baseline's id, so a teammate who has the model URL can locate the exact state being cited.

Step 4 — Tidy up

Baselines accumulate. They count against your storage quota — each one is a full snapshot of the model document at the moment it was taken. When you no longer need an old baseline:

1. Find it in the list.
2. Click Delete.
3. Confirm in the browser dialog.

The baseline is removed immediately. The current model is unaffected. The deletion is permanent — there's no Trash for snapshots.

Working patterns

Milestone baselines

Take one at each formal sign-off or release. Label with the milestone name. Keep them all — the audit trail is the point.

Snapshot before a risky change

Take one with a label like Pre-payments-refactor right before a structural change you're not certain about. If the change works out, delete the baseline a week later; if it doesn't, it's a reference for what you were diverging from.

Snapshot before AI batch changes

When you ask the AI assistant to make sweeping changes — a rename across many elements, a bulk re-stereotype, a multi-step refactor — take a baseline first with a label like Pre-AI-refactor 2026-03-12. The AI is fast; rolling back the bad bits later goes faster when there's a stable reference for what changed.

"As referenced" baselines

When a document or contract quotes the model, take a baseline with a label that ties it back to that document (ADR-017 reference, Procurement RFP attachment). Then the cross-reference is checkable later.

Don't take them too often

A baseline that captures "the model on Tuesday morning" with no narrative reason will get deleted later as noise. Pick a name worth keeping; if you can't, you probably don't need the baseline.

Scripting baselines

The same workspace-membership-authenticated API the UI uses is available from a script — see the XMI export guide for how to mint a long-lived personal access token. Two patterns are worth calling out:

Baseline before deploy

A CI pipeline that touches the architecture (Terraform run, XMI-driven code-gen, ADR publishing) can take a baseline as its first step with a label tied to the build number or git SHA. Then the post-deploy state of the model is always traceable back to a labelled pre-deploy snapshot.

Scheduled baselines

A cron job (GitHub Actions on a schedule, an Azure Function timer trigger) can take a weekly or monthly baseline labelled with the date. Cheaper than asking the architect to remember; more useful than nothing. Keep retention in mind — the storage quota is real and accumulating weekly snapshots is the kind of thing that fills it.

A minimal curl example:

export EO_TOKEN="eo_pat_..."
export EO_HOST="https://api.eomodeller.com"
export WORKSPACE="my-workspace"
export MODEL="my-platform"

curl -fsSL \
  -H "Authorization: Bearer $EO_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST \
  -d "{\"label\":\"deploy-$(git rev-parse --short HEAD)\"}" \
  "$EO_HOST/api/workspaces/$WORKSPACE/models/$MODEL/snapshots"

The response carries the new baseline's id and timestamp; tee it to your build log so you can refer back to the snapshot from CI artefacts.

Troubleshooting

"A baseline with that label already exists for this model"

Labels are unique per model. Use a different label — date-stamping the previous one is the usual fix.

Where's the Baselines tab?

It's on the model property panel, not the diagram or package one. In the package explorer, click the top-level node that's named for the model itself.

I deleted a baseline by mistake

It's gone. There's no Trash for baselines at v1.0. If the situation is critical, contact support — we may be able to recover from the most recent infrastructure backup, but the SLA isn't strong on this.

Can I export the XMI for a specific baseline?

Not yet. XMI export is from HEAD. Snapshot-bound exports are on the post-launch list.

I'm a Viewer; can I still create baselines?

No. Viewer-role teammates see existing baselines but can't create or delete them. Editors and above can.

Reference

• List endpoint: GET /api/workspaces/{workspaceId}/models/{modelId}/snapshots
• Create endpoint: POST /api/workspaces/{workspaceId}/models/{modelId}/snapshots — body {"label":"..."}, returns 201 + summary or 409 on duplicate label
• Delete endpoint: DELETE /api/workspaces/{workspaceId}/models/{modelId}/snapshots/{snapshotId} — returns 204; idempotent
• Authentication: Authorization: Bearer <token> — JWT or PAT (see the XMI guide for how to mint a PAT)
• Required access for create / delete: workspace Editor role or above. List is open to any workspace member.
• Label limit: 120 characters, non-empty after trim
• Storage: each baseline counts against the model's size_bytes, which counts against your tier's storage quota