Admin Cockpit · Journey

Journey: Persona release evidence cycle

A source-reconciled journey record for Admin Cockpit — shipped behavior, state boundaries, failure modes, and the automation evidence available today.

automated · 5 specs
9sections6 minread1table
Markdown source
On this page
Journey at a glance
ActorsPersona governance operatorCalibration reviewerRehearsal operatorPremium-cast approverCustomer member
Systems exercisedtara.mdpersonas.mdreview-id.mdreview.mdrights.md
Automation5 E2E spec(s)

Journey flow#

Generated from the authored steps below — click a node to jump to that section.

flowchart TD s1["1. Read the persona registry"] s2["2. Complete publication governance"] s3["3. Decide a tone-calibration run"] s4["4. Inspect and operate rehearsals"] s5["5. Complete premium-cast approval"] s6["6. Use the separate canonical lifecycle BFF"] s7["7. Verify the separate customer picker"] s8["8. Keep adjacent panels in scope"] s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8 click s1 href "#1-read-the-persona-registry" click s2 href "#2-complete-publication-governance" click s3 href "#3-decide-a-tone-calibration-run" click s4 href "#4-inspect-and-operate-rehearsals" click s5 href "#5-complete-premium-cast-approval" click s6 href "#6-use-the-separate-canonical-lifecycle-bff" click s7 href "#7-verify-the-separate-customer-picker" click s8 href "#8-keep-adjacent-panels-in-scope"

/personas is a real persona-governance cockpit, but it is not one end-to-end release orchestrator. The page combines a read-only registry, editable governance, tone-calibration decisions, rehearsal controls, premium-cast approvals, and voice/avatar review queues. A separate BFF lifecycle state machine controls canonical release status, and a separate customer API controls catalog eligibility and active selection. No current test joins all three lanes into one automatic promotion.

Evidence lane Proven responsibility Boundary
Admin /personas Registry evidence, governance edits, calibration, rehearsal, premium-cast approval Does not expose persona creation or release-channel promotion
Persona lifecycle BFF Validated status transitions, sign-offs, rollback plan, audit Not driven by the Admin page panels
Customer persona picker Consent-gated catalog, select, active, clear Reads released eligibility; does not prove how Admin evidence caused release

Personas#

  • Persona governance operator — has the persona workspace scope and edits publication governance.
  • Calibration reviewer — approves or rejects scored tone runs.
  • Rehearsal operator — starts or completes pre-production dry runs.
  • Premium-cast approver — confirms license, talent, compliance, and rollback attestations before release approval.
  • Customer member — separately grants high-risk voice consent and selects an eligible released persona.

Pre-conditions#

  • An admin session exists and can enter /personas.
  • loadWorkspaceDetail('personas', session) returns the seeded registry, governance, release, voice, and avatar snapshots.
  • The BFF persona lifecycle store is available for the separate canonical transition path.
  • Customer picker tests create their own authenticated member and consent state; they do not reuse the Admin browser session.

Steps#

flowchart LR A[Inspect registry] --> B[Complete governance] B --> C[Decide calibration] C --> D[Run rehearsal] D --> E[Attest premium cast] F[Separate lifecycle BFF] --> G[Released persona] G --> H[Consent-gated customer picker] E -. no proved automatic join .-> F

1. Read the persona registry#

  • The page renders PersonaRegistryPanel with status, channel, approval-gate, evaluation, published-version, disclosure, and release-blocked counts.
  • Entries expose boundaries, versions, disclosure text, rejected or pending gates, and failing or warning evaluations.
  • Release-blocked entries sort ahead of in-review/draft, certified, and retired entries.
  • The registry is read-only. There is no Add persona form and no release-channel selector on this page.

2. Complete publication governance#

  • PersonaGovernanceEditor exposes the seeded governance record for each persona and names incomplete publication blockers.
  • Saving a complete governance patch calls the Admin API and clears the draft persona's blockers after refresh.
  • An inconsistent patch against a published persona returns the publication invariant instead of silently accepting contradictory state.
  • This editor does not verify a cross-workspace /rights consent record or submit a package to /review.

3. Decide a tone-calibration run#

  • ToneCalibrationReviewPanel summarizes pending, approved, rejected, and superseded runs.
  • The focused browser flow approves a scored pending run through its real Admin mutation route and removes its action card after refresh.
  • A calibration decision does not itself advance the separate persona lifecycle status.

4. Inspect and operate rehearsals#

  • RehearsalOutcomesPanel renders scheduled, in-progress, completed, rolled-back, and cancelled states with scenario results, deviations, sign-off, and rollback readiness.
  • Scheduled records expose Start rehearsal; in-progress records expose completion inputs and outcome controls.
  • The current persona release Playwright spec verifies the seeded states and control anatomy, not a complete start → finish mutation round trip.

5. Complete premium-cast approval#

  • A pending approval requires four named attestations: license terms, talent consent, production compliance, and rollback plan.
  • The browser flow toggles all four through real endpoints, approves the record, refreshes, and observes approved.
  • Rejection requires a rationale of at least ten characters.
  • The premium-cast decision is a release-evidence record; it is not proof that the registry channel changed.

6. Use the separate canonical lifecycle BFF#

  • The lifecycle route enforces: drafted → in-review → rehearsal → approved-for-test → approved-for-release → released.
  • Auth and persona-admin scope are required.
  • Release approval without a rollback plan returns 409 lifecycle_transition_invalid.
  • Invalid sign-off envelopes, illegal events, and rollback MTTR above 24 hours fail without status or audit mutation.
  • Successful transitions append lifecycle audit evidence and use optimistic current-status conflict checking.
  • The /personas governance, calibration, rehearsal, and premium-cast controls do not call this transition route automatically.

7. Verify the separate customer picker#

  • The customer BFF withholds high-risk voice personas until consent is granted.
  • After a real consent grant, the member can browse, select, read the active persona, and clear it.
  • Authentication and not-in-catalog failures are explicit.
  • This proves released-catalog eligibility, not that an Admin premium-cast approval published that persona.

8. Keep adjacent panels in scope#

  • Voice-profile and avatar-pack review rows render their seeded status and approval evidence on /personas.
  • Tara sponsor, sequence-script, and nameplate panels are composed on the same page and have their own focused coverage.
  • No tested chain joins those panels to lifecycle release or customer selection.

Post-conditions#

  • Admin evidence can be inspected and the proven governance, calibration, and premium-cast mutations are reflected after refresh.
  • The canonical lifecycle can reach released only through its own validated transition route and rollback gate.
  • A customer with the required consent can select an eligible released persona.
  • Persona creation, automatic evidence-to-lifecycle promotion, review-package submission, channel promotion, staging dwell, and one unbroken audit chain remain unproved.

Failure modes#

  • Missing persona scope — the entry point denies access and persona panels are absent.
  • Incomplete governance — named publication blockers remain.
  • Published-governance contradiction — the API returns the publication invariant and does not accept the patch.
  • Unscored calibration — it cannot be treated as an approvable scored run.
  • Incomplete premium-cast attestations — approval is refused.
  • Stale lifecycle status — optimistic concurrency returns a conflict.
  • Missing or defective lifecycle sign-off — the transition returns 409 without mutation.
  • Rollback plan missing or too slow — live-exposure approval is blocked.
  • Consent absent — the customer catalog reports the blocked persona rather than making it selectable.
  • Lane conflation — matching persona ids across snapshots are not proof of automatic orchestration.

E2E coverage#

Coverage is deep within the three evidence lanes but partial end to end. No current browser test proves automatic Admin evidence → lifecycle release → customer publication.

Per-view files touched by this journey#

Cross-references#

  • review-cycle-admin.md — real generic review decision flow and its own boundaries.
  • isis-lora-training-admin.md — separate voice model training evidence.
  • trust-safety-voice-abuse-response.md — read-only voice-abuse monitoring boundary.
  • apps/oshun/admin/src/app/personas/page.tsx — Admin composition.
  • apps/oshun/bff/src/admin/persona-lifecycle-store.ts — separate lifecycle store.
  • apps/oshun/bff/src/routes/admin-personas-lifecycle.ts — lifecycle HTTP and audit boundary.

Open questions#

  • Which service creates a persona and joins its registry and lifecycle identities?
  • Which evidence gates should automatically authorize each lifecycle transition?
  • Should Admin /personas expose the canonical lifecycle controls directly?
  • How should voice/avatar consent records be joined and freshness-checked?
  • What owns staging dwell, incident-free observation, and rollback execution?
  • Which durable projection publishes a newly released persona into the customer catalog?