# 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:

```bash
# 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**:

```bash
# 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**:

```nickel
# 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**:

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

**Usage**:

```bash
# 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**:

```nickel
# 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**:

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

**Usage**:

```bash
# 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**:

```nickel
# 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**:

```nickel
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**:

```bash
# 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**:

```plaintext
┌───────────────────────────────────────────────┐
│  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**:

```bash
# 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**:

```nickel
# 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

```bash
# 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

```bash
# 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:

```bash
# 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

```bash
# 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:

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

### Increasing Resource Limits

For higher throughput:

```nickel
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:

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

### Custom Logging

For troubleshooting:

```nickel
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

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

### Configuration Export

```bash
# 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

```bash
# 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:

```nickel
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:

```nickel
# 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

```bash
# 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

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

### Copy and Customize

```bash
# 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

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

## Example Structure

Each example is a complete Nickel configuration:

```nickel
# 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

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

### 2. Modify for Your Use Case

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

### 3. Validate Configuration

```bash
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

```bash
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

```nickel
# 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

```nickel
# 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

```bash
# 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