provisioning/schemas/platform/examples

Provisioning Platform Configuration Examples

Production-ready reference configurations demonstrating different deployment scenarios and best practices.

Purpose

Examples provide:

• Real-world configurations - Complete, tested working setups ready for production use
• Best practices - Recommended patterns, values, and architectural approaches
• Learning resource - How to use the configuration system effectively
• Starting point - Copy, customize, and deploy for your environment
• Documentation - Detailed inline comments explaining every configuration option

Quick Start

Choose your deployment mode and get started immediately:

# Solo development (local, single developer)
nickel export --format toml orchestrator-solo.ncl > orchestrator.toml

# Team collaboration (PostgreSQL, RBAC, audit logging)
nickel export --format toml control-center-multiuser.ncl > control-center.toml

# Production enterprise (HA, SurrealDB cluster, full monitoring)
nickel export --format toml full-platform-enterprise.ncl > platform.toml

Example Configurations by Mode

1. orchestrator-solo.ncl

Deployment Mode: Solo (Single Developer)

Resource Requirements:

• CPU: 2 cores
• RAM: 4 GB
• Disk: 50 GB (local data)

Configuration Highlights:

• Workspace: Local dev-workspace at /home/developer/provisioning/data/orchestrator
• Server: Localhost binding (127.0.0.1:9090), 2 workers, 128 connections max
• Storage: Filesystem backend (no external database required)
• Queue: 3 max concurrent tasks (minimal for development)
• Batch: 2 parallel limit with frequent checkpointing (every 50 operations)
• Logging: Debug level, human-readable text format, concurrent stdout + file output
• Security: Auth disabled, CORS allows all origins, no TLS
• Monitoring: Health checks only (metrics disabled), resource tracking disabled
• Features: Experimental features enabled for testing and iteration

Ideal For:

• ✅ Single developer local development
• ✅ Quick prototyping and experimentation
• ✅ Learning the provisioning platform
• ✅ CI/CD local testing without external services

Key Advantages:

• No external dependencies (database-free)
• Fast startup (<10 seconds)
• Minimal resource footprint
• Verbose debug logging for troubleshooting
• Zero security overhead

Key Limitations:

• Localhost-only (not accessible remotely)
• Single-threaded processing (3 concurrent tasks max)
• No persistence across restarts (if using :memory: storage)
• No audit logging

Usage:

# Export to TOML and run
nickel export --format toml orchestrator-solo.ncl > orchestrator.solo.toml
ORCHESTRATOR_CONFIG=orchestrator.solo.toml cargo run --bin orchestrator

# With TypeDialog interactive configuration
nu ../../scripts/configure.nu orchestrator solo --backend cli

Customization Examples:

# Increase concurrency for testing (still development-friendly)
queue.max_concurrent_tasks = 5

# Reduce debug noise for cleaner logs
logging.level = "info"

# Change workspace location
workspace.path = "/path/to/my/workspace"

---

2. orchestrator-enterprise.ncl

Deployment Mode: Enterprise (Production High-Availability)

Resource Requirements:

• CPU: 8+ cores (recommended 16)
• RAM: 16+ GB (recommended 32+ GB)
• Disk: 500+ GB (SurrealDB cluster)

Configuration Highlights:

• Workspace: Production production workspace at /var/lib/provisioning/orchestrator with multi-workspace support enabled
• Server: All interfaces binding (0.0.0.0:9090), 16 workers, 4096 connections max
• Storage: SurrealDB cluster (3 nodes) for distributed storage and high availability
• Queue: 100 max concurrent tasks, 5 retry attempts, 2-hour timeout for long-running operations
• Batch: 50 parallel limit with frequent checkpointing (every 1000 operations) and automatic cleanup
• Logging: Info level, JSON structured format for log aggregation
  • Standard logs: 500MB files, kept 30 versions (90 days)
  • Audit logs: 200MB files, kept 365 versions (1 year)
• Security: JWT authentication required, specific CORS origins, TLS 1.3 mandatory, 10,000 RPS rate limit
• Extensions: Auto-load from OCI registry with daily refresh, 10 concurrent initializations
• Monitoring:
  • Metrics every 10 seconds
  • Profiling at 10% sample rate
  • Resource tracking with CPU/memory/disk alerts
  • Health checks every 30 seconds
• Features: Audit logging, task history, performance tracking all enabled

Ideal For:

• ✅ Production deployments with SLAs
• ✅ High-throughput, mission-critical workloads
• ✅ Multi-team environments requiring audit trails
• ✅ Large-scale infrastructure deployments
• ✅ Compliance and governance requirements

Key Advantages:

• High availability (3 SurrealDB replicas with failover)
• Production security (JWT + TLS 1.3 mandatory)
• Full observability (metrics, profiling, audit logs)
• High throughput (100 concurrent tasks)
• Extension management via OCI registry
• Automatic rollback and recovery capabilities

Key Limitations:

• Requires SurrealDB cluster setup and maintenance
• Resource-intensive (8+ CPU, 16+ GB RAM minimum)
• More complex initial setup and configuration
• Requires secrets management (JWT keys, TLS certificates)
• Network isolation and load balancing setup required

Environment Variables Required:

export JWT_SECRET="<secure-random-256-bit-string>"
export SURREALDB_PASSWORD="<database-password>"

Usage:

# Deploy standalone with SurrealDB
nickel export --format toml orchestrator-enterprise.ncl > orchestrator.enterprise.toml
ORCHESTRATOR_CONFIG=orchestrator.enterprise.toml cargo run --bin orchestrator

# Deploy to Kubernetes with all enterprise infrastructure
nu ../../scripts/render-kubernetes.nu enterprise --namespace production
kubectl apply -f provisioning/platform/infrastructure/kubernetes/*.yaml

Customization Examples:

# Adjust concurrency for your specific infrastructure
queue.max_concurrent_tasks = 50  # Scale down if resource-constrained

# Change SurrealDB cluster endpoints
storage.surrealdb_url = "surrealdb://node1:8000,node2:8000,node3:8000"

# Modify audit log retention for compliance
logging.outputs[1].rotation.max_backups = 2555  # 7 years for HIPAA compliance

# Increase rate limiting for high-frequency integrations
security.rate_limit.requests_per_second = 20000

---

3. control-center-multiuser.ncl

Deployment Mode: MultiUser (Team Collaboration & Staging)

Resource Requirements:

• CPU: 4 cores
• RAM: 8 GB
• Disk: 100 GB (PostgreSQL data + logs)

Configuration Highlights:

• Server: All interfaces binding (0.0.0.0:8080), 4 workers, 256 connections max
• Database: PostgreSQL with connection pooling (min 5, max 20 connections)
• Auth: JWT with 8-hour token expiration (aligned with team workday)
• RBAC: 4 pre-defined roles with granular permissions
  • admin: Infrastructure lead with full access (* permissions)
  • operator: Operations team - execute, manage, view workflows and policies
  • developer: Development team - read-only workflow and policy access
  • viewer: Minimal read-only for non-technical stakeholders
• MFA: Optional per-user (TOTP + email methods available, not globally required)
• Password Policies: 12-character minimum, requires uppercase/lowercase/digits, 90-day rotation, history count of 3
• Session Policies: 8-hour maximum duration, 1-hour idle timeout, 3 concurrent sessions per user
• Rate Limiting: 1000 RPS global, 100 RPS per-user, 20 burst requests
• CORS: Allows localhost:3000 (dev), control-center.example.com, orchestrator.example.com
• Logging: Info level, JSON format, 200MB files kept 15 versions (90 days retention)
• Features: Audit logging enabled, policy enforcement enabled

Ideal For:

• ✅ Team collaboration (2-50 engineers)
• ✅ Staging environments before production
• ✅ Development team operations
• ✅ RBAC with different access levels
• ✅ Compliance-light environments (SOC2 optional)

Key Advantages:

• Team-friendly security (optional MFA, reasonable password policy)
• RBAC supports different team roles and responsibilities
• Persistent storage (PostgreSQL) maintains state across restarts
• Audit trail for basic compliance
• Flexible session management (multiple concurrent sessions)
• Good balance of security and usability

Key Limitations:

• Requires PostgreSQL database setup
• Single replica (not HA by default)
• More complex than solo mode
• RBAC requires careful role definition

Environment Variables Required:

export DB_PASSWORD="<postgresql-password>"
export JWT_SECRET="<secure-random-string>"

Usage:

# Generate and deploy
nickel export --format toml control-center-multiuser.ncl > control-center.multiuser.toml
CONTROL_CENTER_CONFIG=control-center.multiuser.toml cargo run --bin control-center

# With Docker Compose for team
nu ../../scripts/render-docker-compose.nu multiuser
docker-compose -f docker-compose.multiuser.yml up -d

# Access the UI
# http://localhost:8080 (or your configured domain)

RBAC Quick Reference:

Role	Intended Users	Key Permissions
admin	Infrastructure leads	All operations: full access
operator	Operations engineers	Execute workflows, manage tasks, view policies
developer	Application developers	View workflows, view policies (read-only)
viewer	Non-technical (PM, QA)	View workflows only (minimal read)

Customization Examples:

# Require MFA globally for higher security
mfa.required = true

# Add custom role for auditors
rbac.roles.auditor = {
  description = "Compliance auditor",
  permissions = ["audit.view", "orchestrator.view"],
}

# Adjust for larger team (more concurrent sessions)
policies.session.max_concurrent = 5

# Stricter password policy for regulated industry
policies.password = {
  min_length = 16,
  require_special_chars = true,
  expiration_days = 60,
  history_count = 8,
}

---

4. full-platform-enterprise.ncl

Deployment Mode: Enterprise Integrated (Complete Platform)

Resource Requirements:

• CPU: 16+ cores (3 replicas × 4 cores each + infrastructure)
• RAM: 32+ GB (orchestrator 12GB + control-center 4GB + databases 12GB + monitoring 4GB)
• Disk: 1+ TB (databases, logs, metrics, artifacts)

Services Configured:

Orchestrator Section:

• SurrealDB cluster (3 nodes) for distributed workflow storage
• 100 concurrent tasks with 5 retry attempts
• Full audit logging and monitoring
• JWT authentication with configurable token expiration
• Extension loading from OCI registry
• High-performance tuning (16 workers, 4096 connections)

Control Center Section:

• PostgreSQL HA backend for policy/RBAC storage
• Full RBAC (4 roles with 7+ permissions each)
• MFA required (TOTP + email methods)
• SOC2 compliance enabled with audit logging
• Strict password policy (16+ chars, special chars required)
• 30-minute session idle timeout for security
• Per-user rate limiting (100 RPS)

MCP Server Section:

• Claude integration for AI-powered provisioning
• Full MCP capability support (tools, resources, prompts, sampling)
• Orchestrator and Control Center integration
• Read-only filesystem access with 10MB file limit
• JWT authentication
• Advanced audit logging (all requests logged except sensitive data)
• 100 RPS rate limiting with 20-request burst

Global Configuration:

let deployment_mode = "enterprise"
let namespace = "provisioning"
let domain = "provisioning.example.com"
let environment = "production"

Infrastructure Components (when deployed to Kubernetes):

• Load Balancer (Nginx) - TLS termination, CORS, rate limiting
• 3x Orchestrator replicas - Distributed processing
• 2x Control Center replicas - Policy management
• 1-2x MCP Server replicas - AI integration
• PostgreSQL HA - Primary/replica setup
• SurrealDB cluster - 3 nodes with replication
• Prometheus - Metrics collection
• Grafana - Visualization and dashboards
• Loki - Log aggregation
• Harbor - Private OCI image registry

Ideal For:

• ✅ Production deployments with full SLAs
• ✅ Enterprise compliance requirements (SOC2, HIPAA)
• ✅ Multi-team organizations
• ✅ AI/LLM integration for provisioning
• ✅ Large-scale infrastructure management (1000+ resources)
• ✅ High-availability deployments with 99.9%+ uptime requirements

Key Advantages:

• Complete service integration (no missing pieces)
• Production-grade HA setup (3 replicas, load balancing)
• Full compliance and audit capabilities
• AI/LLM integration via MCP Server
• Comprehensive monitoring and observability
• Clear separation of concerns per service
• Global variables for easy parameterization

Key Limitations:

• Complex setup requiring multiple services
• Resource-intensive (16+ CPU, 32+ GB RAM minimum)
• Requires Kubernetes or advanced Docker Compose setup
• Multiple databases to maintain (PostgreSQL + SurrealDB)
• Network setup complexity (TLS, CORS, rate limiting)

Environment Variables Required:

# Database credentials
export DB_PASSWORD="<postgresql-password>"
export SURREALDB_PASSWORD="<surrealdb-password>"

# Security
export JWT_SECRET="<secure-random-256-bit-string>"
export KMS_KEY="<kms-encryption-key-for-secrets>"

# AI/LLM integration
export CLAUDE_API_KEY="<anthropic-api-key>"
export CLAUDE_MODEL="claude-3-opus-20240229"

# TLS certificates (for production)
export TLS_CERT="<certificate-path>"
export TLS_KEY="<key-path>"

Architecture Diagram:

┌───────────────────────────────────────────────┐
│  Nginx Load Balancer (TLS, CORS, RateLimit)  │
│  https://orchestrator.example.com             │
│  https://control-center.example.com           │
│  https://mcp.example.com                      │
└──────────┬──────────────────────┬─────────────┘
           │                      │
    ┌──────▼──────┐      ┌────────▼────────┐
    │ Orchestrator│      │ Control Center  │
    │ (3 replicas)│      │  (2 replicas)   │
    └──────┬──────┘      └────────┬────────┘
           │                      │
    ┌──────▼──────┐      ┌────────▼────────┐     ┌─────────────────┐
    │ SurrealDB   │      │  PostgreSQL HA  │     │  MCP Server     │
    │ Cluster     │      │                 │     │  (1-2 replicas) │
    │ (3 nodes)   │      │  Primary/Replica│     │                 │
    └─────────────┘      └─────────────────┘     │ ↓ Claude API    │
                                                   └─────────────────┘

    ┌─────────────────────────────────────────────────┐
    │        Observability Stack (Optional)           │
    ├──────────────────┬──────────────────────────────┤
    │ Prometheus       │ Grafana        │   Loki      │
    │ (Metrics)        │ (Dashboards)   │ (Logs)      │
    └──────────────────┴──────────────────────────────┘

Usage:

# Export complete configuration
nickel export --format toml full-platform-enterprise.ncl > platform.toml

# Extract individual service configs if needed
# (Each service extracts its section from platform.toml)

# Deploy to Kubernetes with all enterprise infrastructure
nu ../../scripts/render-kubernetes.nu enterprise --namespace production

# Apply all manifests
kubectl create namespace production
kubectl apply -f provisioning/platform/infrastructure/kubernetes/*.yaml

# Or deploy with Docker Compose for single-node testing
nu ../../scripts/render-docker-compose.nu enterprise
docker-compose -f docker-compose.enterprise.yml up -d

Customization Examples:

# Adjust deployment domain
let domain = "my-company.com"
let namespace = "infrastructure"

# Scale for higher throughput
orchestrator.queue.max_concurrent_tasks = 200
orchestrator.security.rate_limit.requests_per_second = 50000

# Add HIPAA compliance
control_center.policies.compliance.hipaa.enabled = true
control_center.policies.audit.retention_days = 2555  # 7 years

# Custom MCP Server model
mcp_server.integration.claude.model = "claude-3-sonnet-20240229"

# Enable caching for performance
mcp_server.features.enable_caching = true
mcp_server.performance.cache_ttl = 7200

---

Deployment Mode Comparison Matrix

Feature	Solo	MultiUser	Enterprise
Ideal For	Dev	Team/Staging	Production
Storage	Filesystem	PostgreSQL	SurrealDB Cluster
Replicas	1	1	3+ (HA)
Max Concurrency	3 tasks	5-10	100
Security	None	RBAC + JWT	Full + MFA + SOC2
Monitoring	Health check	Basic	Full (Prom+Grafana)
Setup Time	<5 min	15 min	30+ min
Min CPU	2	4	16
Min RAM	4GB	8GB	32GB
Audit Logs	No	90 days	365 days
TLS Required	No	No	Yes
Compliance	None	Basic	SOC2 + HIPAA ready

---

Getting Started Guide

Step 1: Choose Your Deployment Mode

• Solo: Single developer working locally → Use orchestrator-solo.ncl
• Team: 2-50 engineers, staging environment → Use control-center-multiuser.ncl
• Production: Full enterprise deployment → Use full-platform-enterprise.ncl

Step 2: Export Configuration to TOML

# Start with solo mode
nickel export --format toml orchestrator-solo.ncl > orchestrator.toml

# Validate the export
cat orchestrator.toml | head -20

Step 3: Validate Configuration

# Typecheck the Nickel configuration
nickel typecheck orchestrator-solo.ncl

# Validate using provided script
nu ../../scripts/validate-config.nu orchestrator-solo.ncl

Step 4: Customize for Your Environment

Edit the exported .toml or the .ncl file:

# Option A: Edit TOML directly (simpler)
vi orchestrator.toml  # Change workspace path, port, etc.

# Option B: Edit Nickel and re-export (type-safe)
vi orchestrator-solo.ncl
nickel export --format toml orchestrator-solo.ncl > orchestrator.toml

Step 5: Deploy

# Docker Compose
ORCHESTRATOR_CONFIG=orchestrator.toml docker-compose up -d

# Direct Rust execution
ORCHESTRATOR_CONFIG=orchestrator.toml cargo run --bin orchestrator

# Kubernetes
nu ../../scripts/render-kubernetes.nu solo
kubectl apply -f provisioning/platform/infrastructure/kubernetes/*.yaml

---

Common Customizations

Changing Domain/Namespace

In any .ncl file at the top:

let domain = "your-domain.com"
let namespace = "your-namespace"
let environment = "your-env"

Increasing Resource Limits

For higher throughput:

queue.max_concurrent_tasks = 200  # Default: 100
security.rate_limit.requests_per_second = 50000  # Default: 10000
server.workers = 32  # Default: 16

Enabling Compliance Features

For regulated environments:

policies.compliance.soc2.enabled = true
policies.compliance.hipaa.enabled = true
policies.audit.retention_days = 2555  # 7 years

Custom Logging

For troubleshooting:

logging.level = "debug"  # Default: info
logging.format = "text"  # Default: json (use text for development)
logging.outputs[0].level = "debug"  # stdout level

---

Validation & Testing

Syntax Validation

# Typecheck all examples
for f in *.ncl; do
  echo "Checking $f..."
  nickel typecheck "$f"
done

Configuration Export

# Export to TOML
nickel export --format toml orchestrator-solo.ncl | head -30

# Export to JSON
nickel export --format json full-platform-enterprise.ncl | jq '.orchestrator.server'

Load in Rust Application

# With dry-run flag (if supported)
ORCHESTRATOR_CONFIG=orchestrator.solo.toml cargo run --bin orchestrator -- --validate

# Or simply attempt startup
ORCHESTRATOR_CONFIG=orchestrator.solo.toml timeout 5 cargo run --bin orchestrator

---

Troubleshooting

"Type mismatch" Error

Cause: Field value doesn't match expected type

Fix: Check the schema for correct type. Common issues:

• Use true/false not "true"/"false" for booleans
• Use 9090 not "9090" for numbers
• Use record syntax { key = value } not { "key": value }

Port Already in Use

Fix: Change the port in your configuration:

server.port = 9999  # Instead of 9090

Database Connection Errors

Fix: For multiuser/enterprise modes:

• Ensure PostgreSQL is running: docker-compose up -d postgres
• Verify credentials in environment variables
• Check network connectivity
• Validate connection string format

Import Not Found

Fix: Ensure all relative paths in imports are correct:

# Correct (relative to examples/)
let defaults = import "../defaults/orchestrator-defaults.ncl" in

# Wrong (absolute path)
let defaults = import "/full/path/to/defaults.ncl" in

---

Best Practices

1. Start Small: Begin with solo mode, graduate to multiuser, then enterprise
2. Environment Variables: Never hardcode secrets, use environment variables
3. Version Control: Keep examples in Git with clear comments
4. Validation: Always typecheck and export before deploying
5. Documentation: Add comments explaining non-obvious configuration choices
6. Testing: Deploy to staging first, validate all services before production
7. Monitoring: Enable metrics and logging from day one for easier troubleshooting
8. Backups: Regular backups of database state and configurations

---

Adding New Examples

Create a Custom Example

# Copy an existing example as template
cp orchestrator-solo.ncl orchestrator-custom.ncl

# Edit for your use case
vi orchestrator-custom.ncl

# Validate
nickel typecheck orchestrator-custom.ncl

# Export and test
nickel export --format toml orchestrator-custom.ncl > orchestrator.custom.toml

Naming Convention

• Service + Mode: {service}-{mode}.ncl (orchestrator-solo.ncl)
• Scenario: {service}-{scenario}.ncl (orchestrator-high-throughput.ncl)
• Full Stack: full-platform-{mode}.ncl (full-platform-enterprise.ncl)

---

See Also

• Parent README: ../README.md - Complete configuration system overview
• Schemas: ../schemas/ - Type definitions and validation rules
• Defaults: ../defaults/ - Base configurations for composition
• Scripts: ../scripts/ - Automation for configuration workflow
• Forms: ../forms/ - Interactive TypeDialog form definitions

---

Version: 2.0 Last Updated: 2025-01-05 Status: Production Ready - All examples tested and validated

Using Examples

View Example

cat provisioning/.typedialog/provisioning/platform/examples/orchestrator-solo.ncl

Copy and Customize

# Start with solo example
cp examples/orchestrator-solo.ncl values/orchestrator.solo.ncl

# Edit for your environment
vi values/orchestrator.solo.ncl

# Validate
nu scripts/validate-config.nu values/orchestrator.solo.ncl

Generate from Example

# Use example as base, regenerate with TypeDialog
nu scripts/configure.nu orchestrator solo --backend web

Example Structure

Each example is a complete Nickel configuration:

# orchestrator-solo.ncl
{
  orchestrator = {
    workspace = { },
    server = { },
    storage = { },
    queue = { },
    monitoring = { },
  },
}

Configuration Elements

Workspace Configuration

• name - Workspace identifier
• path - Directory path
• enabled - Enable/disable flag
• multi_workspace - Support multiple workspaces

Server Configuration

• host - Bind address (127.0.0.1 for solo, 0.0.0.0 for public)
• port - Listen port
• workers - Thread count (mode-dependent)
• keep_alive - Connection keep-alive timeout
• max_connections - Connection limit

Storage Configuration

• backend - 'filesystem | 'rocksdb | 'surrealdb | 'postgres
• path - Local storage path (filesystem/rocksdb)
• connection_string - DB URL (surrealdb/postgres)

Queue Configuration (Orchestrator)

• max_concurrent_tasks - Concurrent task limit
• retry_attempts - Retry count
• retry_delay - Delay between retries (ms)
• task_timeout - Task execution timeout (ms)

Monitoring Configuration (Optional)

• enabled - Enable metrics collection
• metrics_interval - Collection frequency (seconds)
• health_check_interval - Health check frequency

Creating New Examples

1. Start with Existing Example

cp examples/orchestrator-solo.ncl examples/orchestrator-custom.ncl

2. Modify for Your Use Case

# Update configuration values
orchestrator.server.workers = 8  # More workers
orchestrator.queue.max_concurrent_tasks = 20  # Higher concurrency

3. Validate Configuration

nickel typecheck examples/orchestrator-custom.ncl
nickel eval examples/orchestrator-custom.ncl

4. Document Purpose

Add comments explaining:

• Use case (deployment scenario)
• Resource requirements
• Expected load
• Customization needed

5. Save as Reference

mv examples/orchestrator-custom.ncl examples/orchestrator-{scenario}.ncl

Best Practices for Examples

1. Clear documentation - Explain the use case at the top
2. Realistic values - Use production-appropriate configurations
3. Complete configuration - Include all required sections
4. Inline comments - Explain non-obvious choices
5. Validated - Typecheck all examples before committing
6. Organized - Group by service and deployment mode

Example Naming Convention

• Service-mode: {service}-{mode}.ncl (orchestrator-solo.ncl)
• Scenario: {service}-{scenario}.ncl (orchestrator-gpu-intensive.ncl)
• Full stack: full-platform-{mode}.ncl (full-platform-enterprise.ncl)

Customizing Examples

For Your Environment

# orchestrator-solo.ncl (customized)
{
  orchestrator = {
    workspace = {
      name = "my-workspace",     # Your workspace name
      path = "/home/user/projects/workspace",  # Your path
    },
    server = {
      host = "127.0.0.1",        # Keep local for solo
      port = 9090,
    },
    storage = {
      backend = 'filesystem,     # No external DB needed
      path = "/home/user/provisioning/data",  # Your path
    },
  },
}

For Different Resources

# orchestrator-multiuser.ncl (customized for team)
{
  orchestrator = {
    server = {
      host = "0.0.0.0",          # Public binding
      port = 9090,
      workers = 4,               # Team concurrency
    },
    queue = {
      max_concurrent_tasks = 10,  # Team workload
    },
  },
}

Testing Examples

# Typecheck example
nickel typecheck examples/orchestrator-solo.ncl

# Evaluate and view
nickel eval examples/orchestrator-solo.ncl | head -20

# Export to TOML
nickel export --format toml examples/orchestrator-solo.ncl > test.toml

---

Version: 1.0.0 Last Updated: 2025-01-05