Metadata orchestration tutorial

This tutorial shows orchestration emerging from contracts and events instead of hardcoded workflow steps. The Rust cloud runner is the validated path, with TypeScript kept in parity.

By Enrico Piovesan Updated June 22, 2026

Tutorial route

Keep the primary navigation alongside the lesson so the contract and policy links are visible before you reach the footer.

Open source folder All UMA examples Previous: Portability Lab Next: Service Graph Evolution

What you will learn

how emits and subscribes create runtime bindings
how policy fail-open and fail-closed modes affect execution
how CloudEvents and telemetry prove orchestration behavior

Prerequisites

Rust 1.76 or newer
Wasmtime 20 or newer
Node.js 20 or newer
jq and yq are optional

Full tutorial

Enter the example
```
cd chapter-07-metadata-orchestration
```
List the guided labs
```
./scripts/list_labs.sh
```

Run the baseline cloud flow

./scripts/run_lab.sh lab1-baseline-cloud-flow

Verify Rust and TypeScript parity

./scripts/run_lab.sh lab2-rust-ts-parity

Run the fail-closed policy lab

./scripts/run_lab.sh lab3-policy-fail-closed

Run the telemetry audit lab

./scripts/run_lab.sh lab4-telemetry-audit

Run the chapter smoke path
```
./scripts/smoke_orchestration_labs.sh
```

What to inspect

After each command, look for these proof points. They are the signals that connect the code example back to the UMA architecture claim.

binding.created
policy.violation
validation.passed
telemetry.ok

Acceptance check

The chapter-level validation path is:

./scripts/smoke_orchestration_labs.sh

Return to the repository root for the final acceptance gate:

cd ..
./scripts/smoke_reader_paths.sh

Where to go next

Chapter 8 makes service graph evolution inspectable.

Open source folder All UMA examples Read Chapter 8: Contracts and Orchestration → Previous: UMA Portability Lab Next: Service Graph Evolution