Decision Perspective & Persona Voice

What This Covers

This page documents two adjacent capabilities that ship together:

The naming: WWMD is “What Would Mark Do” — the first profile, seeded for the DPF platform itself. WWTD is “What Would They Do” — the generalized model that lets a customer organization encode an executive, a domain expert, or an organizational archetype as its own profile. WWWD is the customer-organization variant of WWMD; in this DPF portal instance, WWMD and WWWD point at the same profile because the business and the product are the same thing.

There is a third scope in the same family. WSID is “What Should I Do” — the profession profile. Where WWMD encodes founder/platform doctrine and WWWD encodes organization doctrine, WSID encodes what a competent professional in a given role should do. Each coworker role family gets its own profile (WSID-DATA-ARCHITECT, WSID-FINANCE, WSID-MARKETING, …) backed by a source-traced professional corpus, reusing the same profile + corpus + retrieval + gate architecture. See The Profession Scope (WSID) below.

Want to see it work, not just read what it is? Decision Perspective in Practice walks a real question end-to-end through the gate for each scope (WWMD / WWWD / WSID) — the options framed, the decision vectors scored, the outcome returned, and the ledger row written — plus how HITL and the immutable ledger wrap every one.

The full design lives in three specs:

What Decision Perspective Does

When a coworker or external MCP client hits a decision point that doesn’t have a deterministic answer in code, it calls the Decision Perspective Gate. The gate selects the active profile, retrieves the principles and prior decisions that bear on the question, aggregates them as a weighted vector across decision dimensions, and returns one of four outcomes:

Outcome Meaning What happens next
recommend Confident direction backed by source-traced principles. The coworker proceeds; the recommendation is logged.
arbitrate Two or more credible directions exist. The gate resolves with weighted vector aggregation and returns the chosen path plus the dissenting view. The coworker proceeds with the chosen path; the dissent is preserved in the ledger.
escalate The decision needs human leadership — confidence is low, sources contradict, or the principle hierarchy doesn’t cover the question. The work pauses; an approval surface is raised to the operator.
defer The active profile lacks enough material to frame even a recommended direction. The question is captured as a profile gap so future curation can close it.

Every invocation writes a DecisionInteraction row recording the active profile version, the source materials cited, the confidence score, the chosen outcome, and the rationale text. This is the audit ledger — auditors and operators reconstruct “what perspective governed this decision, and on what evidence” from it.

The Confidence Model

The gate’s confidence is a governed runtime state, not a model-self-reported number:

Confidence is earned in drops and lost in buckets.

Confidence rises slowly through repeated evidence-backed alignment — a recommendation made, observed in practice, and confirmed by a human, increases the profile’s confidence for that question domain. Confidence drops fast after misses: a contradicted rationale, a stale source, or an overconfident recommendation that turned out wrong pulls the profile back. The point is to make autonomy something the platform earns, not something it claims.

The Inheritance Chain

When the active profile can’t answer a question, the gate falls back through a fixed chain:

  1. Profession profile (WSID) — when the question is a craft question for a coworker with a role profile
  2. Active profile (WWWD or customer-specific)
  3. DPF product doctrine (general platform principles)
  4. DPF organizational principles (TAK / GAID governance layer)
  5. defer — insufficient coverage even for a framing recommendation; capture as a profile gap

The chain is wired into the data model from day one so the fallback path is auditable: every interaction row records which level in the chain produced the answer.

Profile Kinds

The DecisionPerspectiveProfile model supports several profile kinds today. Each profile is versioned — when a profile’s materials change, a new version is snapshotted so old decision interactions still resolve against the doctrine that was active when they ran.

Kind Description Example Status
platform DPF platform doctrine (Mark / DPF Platform). The first profile, seeded with the founder’s writings and approved decisions. Mark / DPF Platform Shipped — the WWMD kernel for this portal instance
organization Customer organization’s operating principles (the WWWD profile). Acme Corp Operating Principles Shipped surface, deferred content — points at the platform profile in this instance because product and business are the same
profession A coworker role family’s professional doctrine (the WSID profile), backed by a source-traced corpus distilled from professional bodies of knowledge. WSID-DATA-ARCHITECT, WSID-FINANCE, WSID-MARKETING Early access — profile kind, source registry, and 23 family profiles seeded; data-architect corpus shipped; finance and marketing are the pilot completion work
customer Future customer-instance profile, isolated from the platform’s product-origin guidance. Customer org doctrine Deferred — not in V1
persona-real A real person who has given explicit documented consent. The voice layer can use their voice clone. An executive at a customer org Shipped surface, consent-gated
persona-fictional A persona not derived from any real person — useful as an archetype profile. “The Pragmatic Founder” Shipped
persona-synthetic An AI-synthesized persona built from curated training data with no real-person basis. Industry archetype seeded by DPF Shipped

The non-negotiable boundary: a customer profile must not inherit platform-specific business judgment as authority by default. DPF product doctrine can be advisory product guidance for any profile; the customer’s own WWWD profile becomes authoritative for its business context once that profile exists.

The Profession Scope (WSID)

WWMD answers “what would the founder/platform do?” and WWWD answers “what would this organization do?” — but a coworker doing a specialist’s job has no governed source for what a competent professional in that role should do. The data-architect coworker has no DAMA-DMBOK grounding; the finance coworker has no GAAP doctrine; the marketing specialist has no marketing body of knowledge. Without WSID, that professional judgment is whatever the underlying LLM happens to produce — ungoverned, unauditable, and inconsistent across model routings.

WSID is the third scope, and it deliberately reuses the architecture the platform already proved twice: a versioned profile + a source-traced corpus + weighted retrieval + an audited gate, scoped to the profession instead of the founder or the org. No parallel storage family is introduced: the corpus lives as WikiPage pages with RawSource provenance, PerspectiveMaterial rows for decision-bearing doctrine, and PostgreSQL embeddings for recall.

Key properties:

Candidate anchor standards for the pilot three (each profession’s research pass confirms, extends, and supersedes them with fetched sources):

SFIA 9 and O*NET/ESCO inform which knowledge areas each role profile must cover — used as a completeness checklist, not ingested as text. WSID does not include verbatim ingestion of licensed/copyrighted texts, per the corpus content policy.

Calling the Gate

In-product coworkers call the gate through the platform’s internal handler — they don’t need to know it exists. The gate is also exposed as an MCP tool so external clients (Claude Code, Claude Desktop, Codex CLI, custom orchestrators) face the same gate under the same governance rules.

An operator can also invoke the gate manually from the Decision Perspective Gate Panel in Build Studio. A typical use is reviewing an automated arbitrate outcome before letting the plan advance — the dissenting view is shown alongside the chosen path so the operator decides whether the resolution holds up.

Tool grants and HITL tiers apply: the gate is callable, but high-risk outcomes (escalate) raise a human approval surface even when invoked autonomously.

The Voice Layer

A persona has three independently configurable layers. None requires the others.

Layer What it is Required for WWTD
Decision materials The principles, decisions, and writings that encode how this person thinks. Stored as PerspectiveMaterial records linked to the profile. This is what the gate evaluates. Yes
Generation style A persona prompt that shapes how the LLM expresses the rationale text — phrasing, cadence, vocabulary. Doesn’t change the decision logic. Recommended
Voice timbre A cloned voice that narrates the synthesized rationale audio. Optional; opt-in per profile

Materials alone produce a fully functional text-only gate. Adding generation style produces styled text rationales. Adding a voice timbre produces audio narration of the styled text. The decision logic is identical across all three configurations.

Speech-to-Text (input)

STT is on by default on every install. The bundled service is speaches — a local Docker service at dpf-stt:9000 running faster-whisper / distil-whisper. No GPU is required; speaches runs CPU-friendly. A 3-tier hardware ladder is available for installs that want to upgrade:

Tier Backend When to use
CPU (default) speaches on CPU Every install gets this. Adequate for normal admin and coworker dictation.
GPU (upgrade) speaches with the CUDA image (DPF_STT_IMAGE env var) Faster, lower-latency transcription on hosts with an NVIDIA GPU.
Hosted Groq / Deepgram / AssemblyAI / OpenAI Whisper Customer-supplied fallback when local STT isn’t desired, or when local hardware is constrained.

The mic button is wired into the coworker chat surface; transcripts feed the existing coworker message pipeline. Errors surface inline rather than silently failing.

Text-to-Speech (output)

TTS narrates decision rationales returned by the gate. Synthesis runs asynchronously after the gate writes the DecisionInteraction row — a TTS provider outage cannot block plan advancement, because audio is always enrichment and text is always the primary output.

The TTS provider is selected with the TTS_PROVIDER env var; the default is self-hosted Chatterbox, so voice stays on your hardware like the rest of the AI workforce. The right backend is operating-system-dependent, because Docker Desktop on macOS has no GPU passthrough — a cloning-grade model can’t be GPU-accelerated inside a Mac container, so Apple Silicon runs a native-host sidecar instead (the same pattern local LLM inference already uses via Docker Model Runner).

Tier Provider Host path GPU Notes
Self-hosted default (Linux / Windows) Chatterbox (dpf-tts container, travisvn/chatterbox-tts-api) amd64 container NVIDIA / CUDA Zero-shot voice cloning. The code default (defaultProvider() falls back to chatterbox).
Self-hosted default (Apple Silicon / non-NVIDIA) mlx-audio (Kokoro fast path + CSM cloning) native macOS host process, reached via host.docker.internal Apple MLX / Metal The macOS path, because Docker Desktop has no GPU passthrough. Mirrors host-native Docker Model Runner. TTS_PROVIDER=mlx.
Cloud (optional) Cartesia Sonic 3 API-only None Lowest first-audio latency (~90ms), streaming-native, no GPU. For installs that don’t want to self-host.
Cloud / quality Fish Audio S2 API or self-host None (API) / RTX 4090 (self-host) High naturalness, enterprise RBAC, self-hostable for data-residency needs.
Fallback ElevenLabs / XTTS v2 (Coqui) API / self-host None (ElevenLabs) / RTX 4090 (XTTS) Stability fallback for pre-rendering, or fully self-hosted budget option.

The default deployment path keeps audio on the host. Cloud TTS is the API-only opt-in for installs that prefer not to self-host or lack a suitable GPU.

The OS-dependent backend split is detailed in docs/superpowers/specs/2026-05-28-tts-apple-silicon-local-design.md (native-host MLX sidecar), which amends docs/superpowers/specs/2026-05-21-chatterbox-tts-self-hosted.md (the Linux/NVIDIA default).

Voice Profile Admin

Voice profiles are managed in the platform’s wiki area at the persona admin page (/coworker-decisions/personas/[id]/voice). Operator workflow:

  1. Upload audio or video samples on the profile admin page
  2. The platform extracts audio from video (FFmpeg, server-side)
  3. Optional vocal isolation removes background noise, music, and other speakers
  4. Consent capture — for any persona-real profile, a structured consent record must be created and confirmed before training runs. This is a non-negotiable gate
  5. The provider training API is called with the processed audio
  6. A VoiceTrainingJob row tracks status: pending → processing → ready → failed
  7. On ready, VoiceProfile.providerVoiceId is set and voiceEnabled can be turned on

Re-training is allowed when sample quality improves or the existing voice degrades. Each training run creates a new VoiceProfile version; the profile points at the current active version.

What an Operator Sees Today

The decision is the primary artifact. A Decision Canvas is the operator-readable projection of a recorded decision: what was asked, which options were available, what the active profile recommended or deferred, which materials pulled the result, and what action comes next.

A material backlink is supporting context, not a second decision. It answers “what else is connected to this cited principle or material?” by showing related stances, heuristics, citations, and prior decisions. Draft or candidate material is held as review material and is not presented as active doctrine.

Research capture is proposal-only. Captured notes, web clips, or Markdown become draft source/material candidates for an explicit target profile. They do not become published wiki pages, promoted profile material, or operational doctrine until reviewed.

Use founder review when a WWMD platform decision needs a missing principle, a founder judgment call, or a platform-governance resolution. Use owner/operator review when a WWWD or custom profile needs organization-local policy, customer-commitment guidance, or an accountable business owner.

Coworker Awareness of the Governance Hub

A coworker chat opened alongside /coworker-decisions can now read the same governance state the page renders, so “what should we do about these open reviews?” is answered from data rather than a request to paste the screen:

Boundaries

Three constraints are non-negotiable:

  1. Voice is a presentation layer. It does not change the decision logic, the confidence model, the escalation rules, or the governance authority. A WWTD profile with a celebrity voice clone follows the same recommend / arbitrate / escalate / defer rules as a text-only profile. Voice makes the output richer; it does not make the profile more authoritative.

  2. Consent is required for any persona-real voice. A structured consent record is stored before any training job can run. Without that record, the training pipeline refuses to start. This is enforced at the data layer, not the UI layer.

  3. Customer profiles do not inherit platform-specific business judgment as authority. Mark / DPF Platform doctrine can be advisory product guidance for any profile, but a customer’s WWWD profile is authoritative for its own business context once it exists.

What’s In Progress

Tracked under EP-WWMD, EP-VOICE-LAYER, and EP-WSID:

Edit this page on GitHub