SCO Workbench

InterSystems Supply Chain Orchestrator (SCO) is a supply chain decision intelligence platform
built on the InterSystems IRIS data platform. It unifies data across your entire supply chain
ecosystem, delivers end-to-end visibility, performs intelligent analysis, orchestrates business
processes, and assists decision making through data, analytics, and AI. SCO enables supply chain
teams to move from reactive firefighting to proactive, data-driven decision making.

SCO Workbench is a UI application which allows application builders to perform common SCO tasks
needed for your supply chain application, such as defining your data model, connecting data sources,
building KPIs and analytics cubes, identifying supply chain risks based on data and client specific
logic, and visualize data and components built in a dashboard — with an optional AI Assistant
that walks you through each form. Note that not all SCO features are exposed through SCO Workbench —
refer to the product documentation for the full capabilities of SCO.

Contents

• Features
• How it works
• Requirements
• Quick start
• Configuration
• AI Assistant
• Troubleshooting
• Learn more
• Contributing

Features

How it works

• One container. The frontend, the backend API and the connection to your instance ship in a
  single Docker image. You point it at your SCO instance and open a browser.
• It works through SCO’s own APIs. The artifacts you create are written into your
  instance the same way you would write them yourself: cube and pipeline classes are compiled into
  your namespace, KPI definitions go through the SCO KPI API, and interoperability hosts are added to
  your production. Everything it creates is an ordinary SCO artifact you can inspect, change or
  remove from the Management Portal, with or without the Workbench.
• Your credentials stay on the server. The browser talks only to the Workbench backend, which
  adds the SCO credentials from your .env server-side. They are never sent to the browser.

Requirements

• Docker with Compose (Docker Desktop, or Docker Engine plus the docker compose plugin).
• A running SCO instance the Workbench can reach: its web port (52773) and superserver port
  (1972) reachable from the machine running Docker, and the name of the namespace you created.
• An account on that instance for the Workbench to act as. Grant it superuser privileges to
  unlock every Workbench capability.
• Optional: access to one Claude provider for the AI Assistant. Without it the Workbench starts
  normally and every non-AI feature works; only the AI-driven actions stand down, and each one says
  so.

Quick start

cp https://github.com/intersystems-community/sco-workbench/blob/main/.env.example .env      # then edit .env: your SCO host, namespace and credentials
docker compose up -d --build

Open http://localhost:3000.

Start on Load sample data if your instance is empty, then work down the Features list. If you
configured a Claude provider, open the AI Assistant with the button at the bottom-right.

To stop it, docker compose down. Your sessions and saved integration cases live in a Docker volume
(workbench-data), so they survive a restart; docker compose down -v deletes them.

Configuration

All settings are read from .env at startup — see https://github.com/intersystems-community/sco-workbench/blob/main/.env.example for the
annotated list. .env is gitignored; never commit it.

The essentials:

Everything else has a working default.

AI Assistant

The AI Assistant is an optional chat panel built on the Claude Agent SDK. Read this section
before using it — it explains what it can change in your environment and what data leaves it.

What it does

It works in Guided mode: it explains the Workbench, answers questions about what already exists
in your instance, and fills in the forms for you while you click the final Save, Build or Deploy.
It can guide these tasks end to end:

1. Build an analytics cube over one of your data model classes.
2. Create or update a Business KPI.
3. Create a data pipeline that ingests external data (file, SFTP/FTP, SQL, S3) into an SCO class.
4. Deploy an interoperability host onto your running production.
5. Answer questions about the instance — which classes, cubes and KPIs exist and how they are
   shaped — by reading your instance rather than guessing.

Deploying a pipeline also copies the files you uploaded into your SCO container.

What leaves your environment

When the AI features run, your configured provider receives: your chat messages; a compact
description of the page you are on and the values in its form; the system prompt and skill
instructions (which include your namespace and port numbers); and the metadata the read-only
tools return — class, property, cube, dimension, measure and KPI names and types, row counts,
production status — plus any ObjectScript generated during the turn.

What the provider does with that (retention, training, region) is governed by your contract with
that provider, not by the Workbench. Sessions and the audit trail are stored locally in the
container’s volume.

Choosing a Claude provider

Pick one of five deployment options with CLAUDE_PROVIDER and set its credentials in .env:

ANTHROPIC_MODEL is required for every provider and its form differs — a Bedrock inference-profile
id, a plain Claude model id, a Vertex model id, or, on Foundry, the Azure deployment name you
chose. https://github.com/intersystems-community/sco-workbench/blob/main/.env.example has a block per provider with the exact variables.

Troubleshooting

Learn more

• Supply Chain Orchestrator documentation
• InterSystems IRIS documentation
• Claude Code third-party integrations —
  the provider matrix behind the AI Assistant

Contributing

Running the app from source is documented separately:

• https://github.com/intersystems-community/sco-workbench/blob/main/docs/development.md — dev environment setup, running in watch mode, the
  test tiers.
• https://github.com/intersystems-community/sco-workbench/blob/main/docs/integration-testing.md — the standard for the live test tiers.