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 platform profile, seeded for DPF itself, carrying founder and platform doctrine. WWWD is “What Would We Do” — the organization profile, which lets a customer organization encode its own stance: an executive, a domain expert, or an organizational archetype. The two are sibling scopes, not a hierarchy, and a customer’s business decision does not inherit platform judgment as authority. In this DPF portal instance WWMD and WWWD happen to point at the same profile, because here the business and the product are the same thing — that coincidence is specific to this install and is not the model.

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

What are the decision dimensions? There are 20 of them, and the set is closed. Each one — what it means, whether it is a benefit or a cost, whether it is shared across every profession or owned by one, and where its weight comes from — is defined in the Decision Vectors reference. How the emphasis shifts by line of business is in Decision Vectors by Business Type.

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 owner 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.

Answering the queue does not make your AI less confident. Confidence carries a discount for how often you have recently OVERRULED a profile in the same decision class — the signal being “our recorded doctrine is drifting from what the owner actually does here, so trust it less”. An overrule means the gate recommended one option and you chose a different one. Simply answering an escalation is not an overrule, and neither is agreeing with the recommendation.

This mattered in practice (BI-ACF0D6D4): the discount used to count every answer, so clearing a review queue drove it to its cap and pushed the NEXT decision below the threshold to act — working through your backlog was what kept the backlog full. Two cases deliberately do not count against you: an escalation that carried no recommendation (there was nothing to overrule), and an answer where you did not pick one of the offered options (that is not evidence of disagreement). Repeated genuine disagreement in a class still lowers autonomy there, which is the point.

Consequential Action Alignment

For a consequential tool call, Decision Perspective is a pre-execution control rather than optional advice. The gate extracts the proposed market, customer, product, geography, and go-to-market motion, then checks them independently against the organization’s published WWWD stance, organization-owned product portfolio, and GTM evidence. An explicit hard boundary in any required corpus vetoes the action; positive signals elsewhere cannot average the veto away.

Only effects that leave the business are checked this way. A tool whose outward effect is platform development or operations (opening a pull request, contributing to the hive, running a discovery sweep, a sign-in handshake) declares consequenceScope: "platform" and is governed by the founder kernel (WWMD) instead: it is still receipted and outward-reviewed, but the business owner is never asked “what should the business do?” about a pull request (BI-63B14D4B). When a business-outward tool carries no descriptive fields, the gate states the parameters it was given rather than escalating a bare tool name.

Which decision admits which tools, for which stage of the work, is modelled by the Gated Permissions Process. The gate described here is the decision side of that pairing.

Product and GTM checks may use a qualified WSID specialist, but qualification never grants permission. The ordinary TAK intersection still requires the actor’s authority, tool grants, workflow policy, data constraints, and preconditions. Owners and employees pass through the same control as coworkers.

There is no alignment bypass flag. To permit an action that the current stance rejects, an owner deliberately amends and publishes the WWWD stance, producing a new policy version, and submits the action for a fresh decision. Every consequential verdict is recorded as a GAID-bound receipt showing the actor, decision interaction, policy version, delegation and qualification evidence, cited sources, and amendment lineage. For an approved action, the receipt channel is reserved before the side effect; if it cannot be reserved, the action does not run.

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 an employee, 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.

Measuring How Often a Coworker Agrees With You

Every six hours the platform counts, for each coworker and each kind of decision, how often the coworker’s recommendation matched what a person then chose. The decision trust report is the report_decision_trust_state tool, available to coworkers and external agents that can read the decision registry.

Read it with three things in mind:

A coworker’s decisions that nobody has resolved yet are shown as unresolved, so a coworker with no resolved decisions still appears in the report.

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.

What Onboarding Seeds for WWWD

A brand-new organization has no recorded stance, so every business question would go to the owner. Onboarding avoids that by seeding a starting WWWD corpus from the captured mission and the chosen business archetype: four identity pages, a “what great looks like” page, and eight stance vectors.

Each vector is a plain-language question with a default answer, worded for the archetype. They are starting positions the owner edits — never a ruling attributed to the owner.

Vector The question it answers
customer-goodwill When something goes wrong on our side
pricing-integrity Prices, quotes, and discounts
growth-vs-stability New opportunities vs existing commitments
quality-bar Our quality standard
spend-authority Spending without asking
data-handling Personal information we hold
routine-operations What the team just gets on with
decision-scope Which decisions are ours to make

Some stances only exist because of what a business actually does. “Under what conditions may we capture an employee’s location?” is a real question for a business whose people drive to customer homes, and meaningless for one whose people never leave the office.

So the activity decides whether the stance is seeded, and the activity is derived from your business type, never asked. A plumbing firm is not asked whether its engineers visit customers; a software platform is never handed a posture about behaviour in someone’s home. Where a business type is genuinely mixed — professional services, some veterinary and care work — the stance is still seeded with a sensible default you can edit, because an editable default costs you one card and a missing one costs you an unanswerable question later.

You will not find a setup question asking which activities apply. If we can work it out, asking you is a tax rather than a check.

The last three exist because the first five cover money and quality, and the decisions that actually reached owners unanswered were none of those — they were personal-data handling, routine operations nobody wanted to be asked about, and questions that were not the business’s to decide at all. A corpus silent on those sends all three to the owner, which is the input the seeding exists to avoid.

decision-scope is the one to read first if your queue is noisy: it states which questions this business owns and which route to a qualified craft or to a supplier, and that a question whose facts are not yet established needs the research rather than a ruling. That reflects decisions belong to their scope — the organization’s business stance has no authority over a craft or platform question, and answering one anyway is the failure mode, not a shortcut.

Each vector lands as an org-scoped wiki page under stances/<vector> plus PerspectiveMaterial rows in the decision classes that consult it, so the gate can find it. Seeded defaults land unconfirmed and carry no decisive weight on their own; confirming them in How you decide during onboarding is what promotes them.

Existing installs converge without operator action: the boot backfill counts the stance pages an org holds against the current vector set, so an install seeded before a vector was added re-runs the idempotent seeding chain once on its next boot and picks it up. Owner-confirmed and owner-ruled material is never downgraded by that re-run.

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.

Ratifying a Policy Once

Autonomy is delegated by a person, not claimed by the platform. When a coworker asks WWMD to authorize an exact, bounded platform action (for example recording a readiness receipt), the authority projector only turns a high-confidence yes into an approval when the policy version that answered was ratified by a human. A fresh install seeds the platform and organization perspectives unsigned, so until someone ratifies them every such action falls to a per-action approval card in your inbox.

Ratify once at /coworker-decisions/perspectives: the platform and organization rows show Ratify this policy until a person with capability management rights clicks it, then show Ratified. The act records your own principal as the root of that delegation; it never overwrites an earlier ratifier, and profession (WSID) doctrine is confirmed on its craft page instead. After ratification, routine exact-bound actions that WWMD answers with a high-confidence, autonomy-eligible yes proceed without a card; anything uncertain, declined, or outside the bound still comes to you (BI-9C384562).

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 oversight levels apply: the gate is callable, but high-risk outcomes (escalate) raise an employee 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 WWWD
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 provider-managed: DPF ships no speech container, and voice input turns on as soon as you configure a provider that can transcribe. Any provider serving an OpenAI-compatible /v1/audio/transcriptions endpoint works.

Option Backend When to use
Self-hosted Your own speech server (speaches, whisper.cpp server — both MIT) Audio never leaves your infrastructure. Ranked first when configured, and the only option cleared for regulated data.
Hosted OpenAI, Groq Nothing to run or maintain. Audio leaves your install, so org vocabulary is redacted before dispatch by the bias-classification gate.

DPF stopped bundling a speech image because a third party’s registry housekeeping was able to block platform releases for every install.

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 the voice is registered. This is a non-negotiable gate
  5. The default self-hosted Chatterbox path is zero-shot: the processed audio is registered as the profile’s reference audio, with no training step
  6. On the opt-in Cartesia path, the clone API is called with the processed audio and the profile’s own status and providerVoiceId record the result; there is no separate training-job record
  7. Once the profile holds a usable voice, 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 WWWD 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