Northline Mechanical is a fictional regional commercial building-services company. Northline Operations connects its business system, field-service platform, and building controls around one unit of work: restoring customer equipment to reliable operation. This example is Sixb's canonical reference application.

From the repository root:

bun install
bun --filter @sixb/example-northline dev

The first start creates deterministic source files and populates Sixb through the real sync, dataset, pipeline, and projection path. The operations app and data plane do not require external credentials.

• Northline Operations: http://localhost:3001
• Atlas: http://localhost:3000
• API documentation: http://localhost:3002/docs

The Northline home route is a branded assistant landing with a centered prompt. Once it creates a durable thread, navigating into the operations app hands that thread to the persistent side dock in the same browser tab.

The button at the bottom-right opens an agent dock with the current route and detail object attached as context. Files open in a closable tabbed canvas over Northline while the dock remains interactive. The dock header keeps collapse, thread history, and one-click compose immediately available. The history dialog shows the current thread, recent activity, and meaningful work status; it becomes a full-page search surface on small screens. The dock's open state, width, and current thread persist independently in each browser tab. Northline configures three language models through Vercel AI Gateway; choose the model and reasoning effort from the composer. The first model is the default.

AI_GATEWAY_API_KEY=your_key bun --filter @sixb/example-northline dev

Without AI_GATEWAY_API_KEY, Northline still starts, syncs, and runs normally; only model-backed assistant turns are unavailable. Customize the model catalog in ai/models.ts and project tools in ai/tools.ts. Agent commands run through the local sandbox provider by default.

To exercise an agent inside a workflow, open Workflows → Agent service assessment in Atlas and request a run with these values:

caseNumber: SC-1042
alarmSeverity: high
contractTier: priority-24-7
summary: RTU-7 supply fan VFD failed while the building is occupied.

The single agent node calls lookup_response_policy and then produces a structured service assessment, making the prompt, tool call, tool result, agent response, and final workflow output available from one run.

Use the smolvm provider when hosting Northline so every agent run executes in a hardware-isolated microVM instead of seeing the host filesystem. The Linux host must expose /dev/kvm to the Sixb service user, and the smolvm binary must be on that user's PATH.

Save the Sixb agent image once with Docker or Podman:

docker pull ghcr.io/sixb-ai/sixb-agent:<version>
docker save ghcr.io/sixb-ai/sixb-agent:<version> -o /opt/sixb/agent.tar

Use the current VERSION for <version>.

Then start the hosted example with smolvm selected and an API origin reachable from inside the VM:

SIXB_SANDBOX_PROVIDER=smolvm \
SIXB_AGENT_IMAGE=/opt/sixb/agent.tar \
SIXB_API_PUBLIC_ORIGIN=https://api.example.com \
AI_GATEWAY_API_KEY=your_key \
bun --filter @sixb/example-northline dev

Do not use a localhost API origin: inside a microVM, localhost refers to the guest itself. Sandbox egress is restricted to the configured Sixb API hostname. See the smolvm sandbox guide for installation, cross-building, and image options.

Open service case SC-1042.

Harbor Foods Group's Newark Distribution Center has an active alarm on rooftop unit RTU-7. The PriorityCare 24/7 contract requires a response within 90 minutes. From Northline Operations you can:

1. Acknowledge the service case.
2. Review and approve the deterministic dispatch recommendation.
3. Open Elena Park's technician workspace and start the visit.
4. Record the failed variable-frequency-drive diagnosis.
5. Approve the repair quote for customer authorization.
6. Complete field work, verify telemetry recovery, and close the case.

The same objects, links, action runs, rule state, workflow runs, datasets, and projections remain inspectable in Atlas.

Run these from examples/northline or through Bun's workspace filter:

bun run demo:reset          # recreate source and runtime state
bun run demo:sync           # reconcile every source through the data plane
bun run demo:alarm          # deliver the signed RTU-7 alarm webhook
bun run demo:approve-quote  # approve a pending source-system quote

Mutable source state lives under .sixb/demo-sources/ and survives ordinary restarts. Only demo:reset replaces it.

Northline deploys to a Linux server with sixb deploy. Deployed, it runs on PostgreSQL and Redis (lib/runtime/production.ts) and stays open to anyone, as it is in development. sixb.deploy.ts reads the server and domain from the environment, so neither is committed.

1. Point *.<your domain> at the server, and have PostgreSQL and Redis running where it can reach them.

2. Set up the server, naming an account on it with sudo:

   cd examples/northline
   export NORTHLINE_DEPLOY_HOST=203.0.113.10 NORTHLINE_DEPLOY_DOMAIN=example.com
   bun run deploy setup --admin <login>

3. Put DATABASE_URL and REDIS_URL in the project's .env on the server; bun run deploy check prints where it goes.

4. Deploy the committed code with bun run deploy. It serves northline-app, northline-atlas, and northline-api under your domain.

The local implementations are typed, validated, atomic file-backed clients. Connectors, syncs, actions, workflows, and the app use those clients rather than importing fixtures. The data plane uses a local DuckDB catalog and local DuckLake storage; its pipeline transformations execute as DuckDB SQL rather than row-by-row TypeScript.

Northline's business.quotes dataset is a complete worked merge sync. The dataset declares quote_id as its primary key, the file-backed business system keeps an ordered quote change log, and sync-business-quotes stores the log cursor as its checkpoint. Initial quotes and later quote decisions are complete-row upserts; the sync also handles exact-key deletes.

Follow the implementation through datasets/business-system.ts, syncs/business-system.ts, and lib/sources/business-system-client.ts.

With Northline running, use the demo commands to see an update flow through the same path:

bun run demo:sync
bun run demo:approve-quote
bun run demo:sync

The second sync reads only the new source event, merges the updated quote, advances the checkpoint, and reevaluates the existing Quote projection against the complete dataset. Run demo:sync again without another source change and the successful no-op creates no dataset version. Atlas shows the dataset's primary key and merge versions in its dataset details.

Follow one connected path rather than browsing by feature:

1. sixb.config.ts
2. ontology/equipment.ts
3. ontology/service-case.ts
4. lib/sources/building-controls-client.ts
5. connectors/building-controls.ts
6. syncs/building-controls.ts
7. pipelines/controls.ts
8. projections/building-controls.ts
9. actions/recordBuildingAlarm.ts
10. actions/dispatchWorkOrder.ts
11. rules/service-operations.ts
12. workflows/service-response.ts
13. ai/models.ts
14. ai/tools.ts
15. app/_components/operations-assistant.tsx
16. app/service-cases/[id]/page.tsx
17. tests/scenario.test.ts

Northline demonstrates connected business behavior, not every Sixb capability. It intentionally omits authentication, accounting, inventory, maps, and route optimization so the primary integration and operational patterns remain easy to understand and copy.