Run Your First Local Workflow

This tutorial takes a first-time developer from a running local runtime to a validated and submitted blueprint. It uses the checked-in medical de-identification blueprint because its configuration declares a local model requirement and review-only outputs; do not use real health documents for this tutorial.

What you will learn

• how to verify the runtime and its local model dependency;
• how blueprint validation prevents submission when a declared requirement is missing; and
• how to inspect the resulting job and run artifacts.

Before you begin

• Complete Installation.
• Start Docker and ensure Docker Model Runner is available.
• Run commands from the MirrorNeuron workspace root.
• Use only the checked-in sample configuration. Do not add private or regulated documents.

Step 1: Start and verify the runtime

mn runtime start
mn runtime health

Continue only when mn runtime health does not report a failed required component.

Step 2: Install and verify the required local model

The blueprint preflight resolves its default model to gemma4:e2b. Install it, then run its diagnostic:

mn model install gemma4:e2b
mn model doctor gemma4:e2b

mn model doctor verifies that Docker Model Runner can use the model on this machine. If it reports a hardware-compatibility problem, stop here and choose a blueprint and model profile that match your available hardware.

Step 3: Validate the blueprint

Validation checks the bundle and declared requirements without submitting a job:

mn blueprint validate otterdesk-blueprints/medical_deid_record_intake_assistant

Verification: the command must exit successfully before you continue. If it reports a missing model or service, resolve that requirement and repeat this step; do not submit the blueprint with --force merely to bypass preflight.

Step 4: Submit the workflow

mn blueprint run --folder otterdesk-blueprints/medical_deid_record_intake_assistant

The command prints a job ID and may print a run ID. Record both values: the job ID controls the runtime execution, while the run ID identifies blueprint artifacts.

Step 5: Verify and inspect the result

Replace <job_id> and <run_id> with the values from the launch command:

mn job status <job_id>
mn job monitor <job_id>
mn blueprint logs <run_id>

A terminal job state is completed, failed, or cancelled. The blueprint writes run records under ~/.mn/runs/<run_id>/ by default. Inspect its artifacts before treating any output as usable: this blueprint produces a review packet, not an approval to release or share records.

What happened

The CLI validated the blueprint before submission, then the runtime created a job and scheduled its agents. Job inspection reads runtime state; blueprint log commands read the run-store records associated with the launch. The blueprint's runner, model configuration, inputs, and pass_env entries determine what it can access.

Clean up

Cancel an unfinished job before stopping local services:

mn job cancel <job_id>
mn runtime stop

Do not delete ~/.mn/runs/<run_id>/ until you no longer need the event history and artifacts.

Next steps

• Examples to choose a blueprint for your workload and hardware.
• Core Concepts to understand jobs, runs, agents, and runtime nodes.
• Security Model before providing real data or secrets.