dfaas-wanderland-mapping

DFAAS → Wanderland Implementation Mapping

Type: Implementation Guide
Status: Planning
Source: component-dfaas
Target: Wanderland Platform

Overview

This document maps DFAAS features to Wanderland primitives. The goal is not to port DFAAS code, but to show how Wanderland's existing architecture already provides the building blocks.

Key insight: DFAAS injects everything into every request (dumb pipe). Wanderland uses tools/fences (agent approach). Agents fetch what they need, not everything upfront.

Feature Mapping

WTF Pattern Deep Dive

The wtf-am-i-doing node provides real-time activity awareness by analyzing MCP tool call logs:

mechanism:
  data_source: mcp-proxy SQLite logs
  analysis: Python executable fences
  outputs:
    - quick-check: Last N hours activity summary
    - hourly-breakdown: Activity grouped by hour  
    - themes: Recurring patterns and focus areas
    - nodes-touched: Which parts of the graph changed

key_insight: |
  Every MCP tool call is logged with context strings.
  By analyzing these logs, you get automatic "what changed" 
  for free - no explicit tracking needed.

Usage:

# Quick activity check
____execute({ fence_id: "wtf-am-i-doing:quick-check", params: { hours_back: 4 } })

# Theme extraction
____execute({ fence_id: "wtf-am-i-doing:themes", params: { hours_back: 8 } })

Page Composition for Delta Tracking

For domain-specific delta tracking (like DFAAS forecast changes):

Create a tracking page: Compose all tracked items onto a single page
Page = API: The page composition becomes an API endpoint
Rendering = current state: Looking at the page shows current state
Versioning = history: Node versioning provides diff capability

# Example: forecast-delta-tracker page
compose:
  - forecast-week-current.status.yaml
  - forecast-accuracy-kpi@L4
  - active-exceptions.count
pattern: "The page composition IS the delta definition"

1. Quick Reference / How-To Guides

DFAAS Approach: Static documentation strings injected into system prompt

Wanderland Implementation: ✅ Already Solved

DFAAS	Wanderland
`quickReference.resolveException`	Reading list node
`quickReference.runForecast`	Reading list node
`platformDocumentation`	Reading list execution

How it works:

# User asks "how do I lock a forecast?"
# Agent executes:
____execute({ fence_id: "get-reading-list", params: { topic: "forecast-locking" } })

Reading lists are curated sequences of nodes. Execute the reading list, get the guidance. No injection needed.

Action: Create reading lists for forecasting workflows

2. Role-Specific Workflow

DFAAS Approach: Role guidance strings in system prompt per user type

Wanderland Implementation: ✅ Personas + Reading Lists

DFAAS	Wanderland
`roleGuidance.demandPlanner`	Persona fragment + role reading list
`roleGuidance.demandAnalyst`	Persona fragment + role reading list
`roleGuidance.supplyChainManager`	Persona fragment + role reading list

How it works:

# Load persona for session context
_____persona({ name: "demand-planner" })

# Or execute role onboarding
____execute({ fence_id: "execute-reading-list", params: { topic: "demand-planner-onboarding" } })

Action: Create demand planning personas with role-specific fragments

3. Change Delta / What Changed

DFAAS Approach: change-tracking.ts compares current state to "last refresh time"

Wanderland Implementation: ✅ Multiple Primitives Available

DFAAS	Wanderland Option
`getChangeSummary()`	`wtf-did-i-do-yesterday` node
Changes since last view	Version history on nodes
Activity tracking	Investigation notes on cases

Proposed Enhancement: Page-Level Delta Tracking

Add attribute to nodes/fences:

delta_tracking: true
delta_window: "24h"  # or "session" or "7d"

When you ______look at a delta-tracked page:

## Today's View

[normal content]

## Changes Since Yesterday
- Line 45: accuracy threshold changed 75% → 80%
- Section "Exceptions": 3 new items added
- Fence [kpi-summary]: output changed

Implementation:

Already have version history (_____history, _____version)
Add diff display on look when delta_tracking: true
Store "last viewed" timestamp per user/session

Action: Add delta_tracking attribute to fence/node schema

4. Live KPIs / Metrics

DFAAS Approach: getDashboardKPIs() called on every chat request, injected into prompt

Wanderland Implementation: 🔧 Fences as Tools

DFAAS	Wanderland
`kpis.forecastAccuracy`	Fence: `forecast-accuracy-kpi`
`kpis.avgBias`	Fence: `forecast-bias-kpi`
`kpis.openExceptions`	Fence: `exception-count`
`getAccuracyByCategory()`	Fence: `accuracy-by-dimension`

Key difference:

DFAAS: Inject all metrics every request (wasteful, bloats context)
Wanderland: Agent calls fence when it needs the data (efficient)

How it works:

# Agent decides it needs accuracy data
____execute({ fence_id: "accuracy-by-category" })

# Returns structured data agent can reason about

Fence Definition:

fence_id: accuracy-by-category
type: virtual
description: "Get forecast accuracy broken down by product category"
handler: |
  // Query accuracy metrics
  // Format as table
  // Return markdown
output_format: markdown_table

Action: Create KPI fences that query underlying data

5. Exceptions / Alerts → Amygdala Pattern

DFAAS Approach: generateExceptions() scans data, returns prioritized list with impact scores

Wanderland Implementation: 🔧 Amygdala + Fence Metadata

DFAAS	Wanderland
Exception detection	Pattern triggers on fence execution
Impact scoring	Alert metadata on fence
Auto-resolution	Pattern with auto-clear condition
Exception feed	Virtual fence querying active alerts

The Amygdala Pattern:

Attach patterns to fences. When fence executes, if data matches pattern → alert fires.

# On a KPI fence
fence_id: category-accuracy
patterns:
  - name: accuracy-drop
    condition: "value < 70"
    severity: critical
    message: "Accuracy dropped below 70%"
  
  - name: accuracy-warning  
    condition: "value < 80"
    severity: high
    message: "Accuracy below target"

When fence executes and pattern triggers:

Alert attached as metadata to fence
has_alert: true flag set
Alert details in alert_data: { severity, message, triggered_at, value }

Querying Alerts:

# Virtual fence that finds all fences with active alerts
____execute({ fence_id: "active-alerts", params: { severity: "critical" } })

Simpler Alternative:

Just make alerts values on fences:

fence_id: gaming-accuracy
value: 68.5
alert: 
  active: true
  severity: critical
  message: "Gaming accuracy 68.5% < 70% threshold"
  triggered: "2026-01-25T10:00:00Z"

Then any query for fences-with-alerts just filters on alert.active: true.

Action:

Add patterns array to fence schema
Add alert metadata field to fence schema
Create active-alerts virtual fence

6. Consensus / Lock Workflow

DFAAS Approach: isLocked, lockedBy, lockedAt fields on forecast records

Wanderland Implementation: 🔧 Node/Fence State Machine

DFAAS	Wanderland
Lock status	Node metadata: `status: locked`
Lock audit	Node metadata: `locked_by`, `locked_at`
Unlock request	Case/ticket for approval

How it works:

Forecast data lives in nodes. Lock is just metadata:

# forecast-week-2026-w05.md
---
status: locked
locked_by: "Sarah Johnson"
locked_at: "2026-01-24T16:00:00Z"
lock_reason: "Consensus approved"
---

## Week 5 Forecast
...

To unlock, create a case/ticket:

_______new({ 
  project: "FORECAST", 
  summary: "Unlock request: Week 5", 
  description: "Need to adjust for promotional event"
})

Action: Define forecast node schema with lock metadata

7. Scenario Planning

DFAAS Approach: scenarios: { baseline, optimistic, pessimistic, promotional } on each forecast

Wanderland Implementation: 🔧 Scenario Nodes + Comparison Fences

DFAAS	Wanderland
Baseline scenario	Node: `forecast-2026-baseline`
Optimistic scenario	Node: `forecast-2026-optimistic`
Scenario comparison	Fence: `compare-scenarios`

How it works:

Each scenario is a node with the same structure. Compare fence diffs them:

____execute({ 
  fence_id: "compare-scenarios", 
  params: { 
    scenarios: ["baseline", "optimistic", "promotional"],
    metrics: ["total_units", "revenue", "accuracy"]
  }
})

Action: Define scenario node template, create comparison fence

8. Onboarding Wizard

DFAAS Approach: 10-step wizard in /setup/page.tsx collecting company profile, branding, auth, data uploads

Wanderland Implementation: 🔧 Wizzy State Machine

DFAAS	Wanderland
Setup wizard	Wizzy YAML state machine
Step validation	Fence-based validation
Data upload	Stuffy upload → processing fence

Wizzy Definition:

wizard_id: dfaas-onboarding
steps:
  - id: company
    prompt: "What's your company name?"
    fields: [company_name, industry, timezone]
    validation: required
    
  - id: branding
    prompt: "Upload your logo (optional)"
    fields: [logo_url, color_theme]
    optional: true
    
  - id: master-data
    prompt: "Upload your item master CSV"
    type: file_upload
    handler: fence:process-item-upload
    
  # ... etc

Action: Create DFAAS onboarding Wizzy definition

Summary: What Needs Building

Already Have (No Work)

✅ Quick reference → Reading lists
✅ Role workflows → Personas + reading lists
✅ Version history → _____history, _____version
✅ Activity tracking → Investigation notes, WTF node
✅ "What changed" feed → WTF pattern (MCP log analysis)
✅ Delta composition → Page composition pattern (compose items → page becomes API)

Enhancement Needed

🔧 delta_tracking: true attribute on nodes/fences (optional enhancement for explicit tracking)
🔧 Alert/pattern attachment to fences (Amygdala pattern)
🔧 active-alerts virtual fence

Note: Delta tracking is mostly solved via WTF pattern + page composition. The delta_tracking attribute is an optional enhancement for explicit "show me what changed on this specific item" use cases.

New Fences to Create

📝 forecast-accuracy-kpi
📝 accuracy-by-dimension
📝 exception-count
📝 compare-scenarios
📝 active-alerts

New Node Templates

📝 Forecast week template (with lock metadata)
📝 Scenario template
📝 Exception/alert template

Wizzy Definition

📝 DFAAS onboarding wizard

Architecture Difference

DFAAS (Dumb Pipe)                    Wanderland (Agent + Tools)
─────────────────                    ─────────────────────────

┌─────────────────┐                  ┌─────────────────┐
│   User Query    │                  │   User Query    │
└────────┬────────┘                  └────────┬────────┘
         │                                    │
         ▼                                    ▼
┌─────────────────┐                  ┌─────────────────┐
│ Build Giant     │                  │ Agent Decides   │
│ System Prompt   │                  │ What It Needs   │
│ (inject ALL     │                  └────────┬────────┘
│  metrics,       │                           │
│  exceptions,    │                  ┌────────┼────────┐
│  docs, etc)     │                  │        │        │
└────────┬────────┘                  ▼        ▼        ▼
         │                        ┌─────┐ ┌─────┐ ┌─────┐
         ▼                        │Fence│ │Fence│ │Node │
┌─────────────────┐               │ KPI │ │Alert│ │ Doc │
│   Claude API    │               └──┬──┘ └──┬──┘ └──┬──┘
│   (bloated      │                  │       │       │
│    context)     │                  └───────┴───────┘
└────────┬────────┘                          │
         │                                   ▼
         ▼                           ┌─────────────────┐
┌─────────────────┐                  │ Agent Responds  │
│    Response     │                  │ (lean context,  │
└─────────────────┘                  │  fetched data)  │
                                     └─────────────────┘

Wanderland wins: Agent fetches only what it needs. Context stays lean. Tools are reusable.

Slots

North

slots: []

South

slots: []

East

slots: []

West

slots:
- slug: component-dfaas
  context:
  - Linking component spec to its Wanderland implementation mapping

Provenance

Document

Status: 🔴 Unverified

Changelog

2026-01-25 19:23: Node created by mcp - Implementation mapping for rebuilding DFAAS on Wanderland primitives - showing how existing Wanderland features cover DFAAS functionality

Already Have No Work

Enhancement Needed

← westcomponent-dfaas