1
Open support cases
TR-2517 internal admin operations
Review queues, escalation pressure, and audit evidence in one calm surface.
This admin surface stays read-heavy by default. It separates support review, sensitive exceptions, trust surfaces, and audit posture so operations do not collapse into one blurry page.
What needs attention now
0
Escalation-flagged assistant events
1
Aging open cases
0
Billing-sensitive cases
Admin surface map
The ops surface should feel like one coherent control plane, not a pile of disconnected internal tools.
Overview
Attention now, aging work, degraded states, and pending review signals.
Support and operations
Support intake, escalations, repeated blockers, and incident-adjacent review.
Billing and hardship
Sensitive exception review separated from normal support inspection.
Content and trust surfaces
Public-trust review, parity posture, and content approval awareness.
Product controls
Bounded launch toggles with visible owner, scope, and consequence.
Reporting and analytics
Canonical metrics and actionable signals, not vanity dashboards.
Audit and history
Evidence-first timelines for what happened already.
System and access
Privilege-sensitive references isolated from routine admin flow.
Saved views
Operator-first slices for the most likely review lanes.
Segmented support lanes
Separate the queue by work type before any review action exists.
CHMS operating core
Open the live CHMS workspace for people, households, scope, and audit.
Privilege boundary map
Seeing a record should not imply broad change rights, and sensitive areas should feel structurally distinct.
Sensitivity classes
- Normal admin visibility
- Restricted business-sensitive visibility
- Restricted financial visibility
- Restricted identity or access visibility
- Platform-admin visibility
Boundary rules
- Support visibility does not imply billing or access mutation rights.
- Read-heavy inspection stays separate from consequence-heavy changes.
- Platform-admin surfaces should remain visually isolated from routine ops.
Queue filters
Direct filters still exist when you want a narrower slice than the saved views.
Support triage queue
Rows expose lane, age, sensitivity, status, and a safe drill-in path.
| Case | Lane | Category | Urgency | Status | Sensitivity | Created | Age | Next safe action |
|---|---|---|---|---|---|---|---|---|
| tr-72zuwbby Transparent QA Church · Transparent Test User Trial start | Transparent QA Church | Transparent Test User | path:self_serve | General support | trial_start | medium | submitted | Normal admin visibility | Apr 28, 10:20 PM | 4d old | Open detail → |
Billing and hardship review posture
Sensitive exception workflows should be visible as distinct review lanes even before mutation flows exist.
What is visible now
Billing-sensitive cases: 0
Hardship lane: 0
Billing lane: 0
What remains deliberately separate
- Customer-visible consequence preview before changes
- Approval and denial actions with audit linkage
- Step-up auth for meaningful financial mutations
Escalation and assistant event review
Assistant behavior stays visible so weak grounding and sensitive topics do not disappear into polished prose.
partially grounded use caution
Grounded answer, but keep the boundary in view
How does the two-month trial work if our church may need guided migration help?
Content and trust surfaces
Public-trust promises need visible review posture even before a full approval queue exists.
Trust-surface review posture
- Pricing, help, and support promises should remain mutually consistent.
- EN and ES parity should stay visible for trust-sensitive content.
- Draft, approved, and published distinctions should remain explicit later.
Current bounded reference points
Reporting, audit, and system posture
Canonical metrics, evidence-first history, and privilege-sensitive references should stay distinct.
Reporting and analytics
Canonical metrics should lead. AI explanation, if it appears later, should remain visually secondary to governed reporting truth.
Audit and history
Evidence-first presentation should make actor, target, action, and result status easy to scan before any mutation tool exists.
System and access
Privilege-sensitive references should stay isolated from routine support operations and never blur into casual navigation.
Launch gate posture
The internal shell should make final readiness review explicit before any real go-live claim exists.
What the gate should inspect
- Launch domains with attributable evidence
- Critical-path validation with pass/fail truth
- Blocker versus follow-up classification
- Explicit go / hold / no-go posture
Current bounded surface
Open launch-readiness review shell →Recent audit and history
Recent evidence-first activity for queue and assistant flows.
bounded_store_saved
Target: bounded_store · tr2590-comms-workflow-store
Result: success · Actor: system · Surface: ops_chms
support_assistant_responded
Target: support_event · 841fbad0-6878-4585-b581-328934200ac9
Result: success · Actor: public_user · Surface: support_assistant
support_case_submitted
Target: support_case · tr-72zuwbby
Result: success · Actor: public_user · Surface: public_intake
High-risk action inventory
This surface stays read-heavy, but it should still make higher-consequence mutation classes explicit.
High-risk classes
- Access or role changes
- Hardship approval or denial
- Billing override or exception issuance
- Feature-flag changes affecting user-visible truth
- Public trust-surface approvals
- Import or correction approvals
- Refund, dispute, or other financial-state mutations
Required mutation flow posture later
- Pre-action context
- Consequence statement
- Preview or diff where meaningful
- Explicit confirmation and audit linkage
- Step-up auth where required
Launch-default operator guidance
The queue shell also anchors the first macro and severity map so operations stay consistent.
Macro families
- Acknowledgement
- Clarifying question
- Grounded answer
- Escalation
- Restricted-path
- Billing and hardship sensitivity
Severity model
| S0 | Critical trust or platform emergency |
|---|---|
| S1 | Major service-impact incident |
| S2 | Blocked high-value workflow or meaningful degradation |
| S3 | Normal support issue or localized defect |
| S4 | Informational or low-impact request |