Most dental AI vendor governance documents are aspirational. They list what the company will do once they have a real practice running. Velyn Dental's governance is different — it's grounded in apps/portal/lib/anthropic/policy-registry.ts and governance-store.ts, which decide on every call what gets reviewed by a human and what gets to fall back automatically.

The policy registry has two relevant settings per workflow:

reviewMode: 'always' — every output requires human review before it reaches the patient or the front desk.
reviewMode: 'never' — outputs flow without a human checkpoint, but unsafe or ungrounded outputs trigger deterministic fallbacks and log to governance telemetry.

The default for any new workflow is reviewMode: 'always'. Today, five workflows have a documented reviewMode: 'never' exception. Each exception has a written rationale in docs/partner/anthropic/governance.md. This post walks through all five.

Why these exist at all

Live patient calls cannot pause for human review. A 3-second latency on routing a patient with a chipped tooth to the on-call provider is acceptable; a 30-second latency while a human moderator reviews the Claude output is not. The same logic applies to post-call archive processing — the call is already over, blocking the archive on human review doesn't add safety, it adds drag.

The exception design pattern is consistent across all five: non-blocking output + deterministic safety floor + telemetry logging. Claude does the reasoning. If Claude produces something unsafe or ungrounded, the deterministic floor takes over and the event lands in governance telemetry for later review — not in a queue that holds the call hostage.

Exception 1: speech_routing (live IVR)

Live IVR routing must stay non-blocking. The caller is on the line, the model has milliseconds, and the routing decision (book this routine call, transfer this to staff, escalate this to on-call) is happening in real time.

The speech_routing workflow keeps reviewMode: 'never'. When Claude emits a POLICY_VIOLATION, GROUNDING_DRIFT, or HIGH_RISK_ACTION finding, the runtime logs the finding to governance telemetry and falls back to the deterministic rule path instead of pausing for human review.

The deterministic floor here is the rule-based routing engine: keyword-driven escalation paths, hard-coded emergency triggers, the staff-handoff rules the practice approved during setup. Claude's reasoning is the first path; the rules are the only path when Claude is wrong.

Exception 2: transcript_redaction (post-call archive)

Post-call archive processing must not block. Once the call ends, the practice expects the transcript and summary to land in the archive without a human gating step.

The transcript_redaction workflow keeps reviewMode: 'never'. Deterministic regex redaction runs first — that's the authoritative pass. Claude may then validate the redaction (catching contextual PHI the regex missed: "the patient I saw last Tuesday at 3pm" doesn't trigger SSN regex but is identifying), but if Claude's validation is unsafe or fails entirely, the regex output wins and the archive proceeds.

The deterministic floor is the regex pattern set. Claude is additive — it can catch what regex misses, but cannot break what regex caught.

Exception 3: practice_ai_insights (internal analytics)

practice_ai_insights powers the internal partner-evidence analytics briefings — the dashboards that show how Claude is performing per practice. These are internal and non-patient-facing.

This workflow keeps reviewMode: 'never' because the output is read by the COE during weekly review, not seen by patients or staff. Unsafe or ungrounded outputs still log to governance telemetry, and the runtime falls back to deterministic insights instead of creating human-review queues for sales-deck copy.

The deterministic floor is the metric-aggregation layer in governance-store.ts — average latency, tool success rate, fallback rate, review-required rate, reviewer-override rate, hallucination-catch count and rate. Those are mathematical aggregates that don't require Claude to compute.

Exception 4: realtime_triage_handoff (live in-call handoff)

This one is the strictest exception, with the most explicit guardrails. When a live caller needs to be handed off to human staff during the call, Claude makes the routing decision and the call moves immediately. There's no time for a human-review checkpoint without dropping the caller.

The realtime_triage_handoff exception is scoped through a new allowedActions field on the policy. The closed set is warm_transfer and callback_queue — those are the only actions Claude is allowed to emit. The Claude tool MUST NOT:

Make clinical or diagnostic statements
Assert insurance coverage claims
Assert urgency beyond the routing decision

The eval suite enforces these forbidden output classes. Any other emitted action is treated as a policy violation by the eval, which means any drift from the allowed-action set triggers the deterministic-keyword path as the safety floor. Manual Portal push (a human in the COE pressing "escalate this caller now") remains the override of last resort.

Tool arguments coming back from Claude are treated as untrusted. The IVR redacts the transcript excerpt at the apps/ivr/tools.py boundary before any logging, Sentry breadcrumb, Redis write, or Portal POST. This means even if Claude leaked PHI into a tool argument, the redaction happens before the PHI reaches any persistence or observability surface.

This exception was ratified 2026-05-15 against policy-registry version 2026-05-07.1.

Exception 5: outbound_recall (live patient-facing recall) — DRAFT

The fifth exception is currently in DRAFT status, pending COE ratification with the dental outbound-recall sprint PR. The live patient-facing AI outbound recall flow cannot accept in-call human-review checkpoints because they would create awkward pauses for the patient on the other end.

The safety floor for this exception is the most layered of the five — three independent deterministic checks:

Regex emergency detection short-circuits any unsafe response to an emergency-handoff path.
Slot-offer validation rejects any proposed appointment time that does not match a row in PracticeSlotPool.
Stripe meter dedup prevents duplicate revenue-recovery billing events even if Claude (or its tool calls) misfires.

The kill switch is database-backed. OutboundConfig.dentalOutboundEnabled is a singleton flag; Practice.outboundEnabled is per-practice. Both default to disabled. The flag is in the database (not in code), which means turning it off doesn't require a deploy.

The exception is scope-locked: outbound recall voice only. Any attempt to reuse this exception pattern for other workflows requires a fresh COE review.

The overclaim guardrail

These exceptions don't dilute the partner claim — they tighten it. The governance doc carries an explicit overclaim guardrail:

No partner-facing doc in this repo may claim "fully Claude-native dental runtime" while any of the following remain true:

apps/portal/app/api/ivr/speech/route.ts still depends on mixed-provider fallback behavior

apps/ivr/relay.py remains the live mixed-provider receptionist relay path

Both conditions were resolved on March 16, 2026 (covered in the previous post in this series). The overclaim guardrail still applies for any future expansion that might re-introduce mixed-provider behavior.

The guardrail is architectural, not optional marketing language. The text doesn't soften it. The COE doesn't have permission to wave it through. If a feature ships that re-introduces a mixed-provider path on the IVR, the partner claim has to be downgraded the same day.

Governance telemetry — the metrics we actually publish

The five exceptions all log to governance telemetry. That telemetry is exposed through apps/portal/app/api/practices/[practiceId]/ai-governance/summary/route.ts, with concrete metrics:

averageLatencyMs — how fast Claude responds across workflows
toolSuccessRate — what fraction of tool calls succeed
fallbackRate — what fraction of calls fall back to the deterministic floor
reviewRequiredRate — what fraction of outputs need human review
reviewerOverrideRate — what fraction of human reviews override the model output
hallucinationCatchCount and hallucinationCatchRate — how often the safety floor catches an ungrounded output

The pack references these as a real governance capability. The metrics are practice-scoped — we don't commit per-practice values to git, but the surface exists, the API route is implemented, and the dashboards consume it during weekly COE review.

The COE meeting cadence

Per docs/partner/anthropic/governance.md:

Weekly — COE reviews Claude runtime changes, MCP changes, eval changes, and deployment-policy changes once per week.
Quarterly — Once per fiscal quarter, the COE rolls 13 weeks of weekly notes into a forward-looking checkpoint. The quarterly note adds drift classification, partner-claim posture, exception sunset audit, and role-seat status.

The COE seats:

Founder / Product & AI Systems Owner — Bryan Mathews
Clinical Workflow Lead — Role seat, target named by 2026-06-01
Platform / Integration Lead — Role seat, target named by 2026-06-01

The two vacant seats are tracked as known tech debt (item #2 in the May 2026 tech-debt audit). Bryan is fallback reviewer of record on every COE-controlled path until both seats are mapped to GitHub handles. That bus-factor risk is named and tracked, not glossed over.

The sub-processor BAA question

One last governance detail that's specific to dental AI receptionists: when call audio flows through Twilio ConversationRelay → apps/ivr/relay.py → Anthropic Messages API, Anthropic becomes a downstream PHI recipient. Twilio's Media Streams rule assigns downstream-recipient HIPAA-compliance responsibility to the customer (us), which means we need an Anthropic BAA covering each practice ID whose audio passes through ConversationRelay before that practice's first PHI-bearing call is allowed.

The BAA coverage table is in the governance doc. As of writing, no real practice is onboarded yet — KERNEL_PRACTICE_ID points at the Bright Smile demo placeholder. When the first real practice onboards, a row gets appended to the table before that practice's first PHI-bearing call. That ordering matters.

This post is the second in a three-part series on Velyn Dental's Claude-native architecture. The previous post covered the architecture itself and the March 2026 migration. The next post covers the 199-case eval baseline that runs before any model change lands.