TenantAtlas/docs/ui-ux-enterprise-audit/target-experience-briefs/provider-readiness.md

Provider Readiness Target Experience Brief

Metadata

Field	Value
Surface IDs	UI-072, UI-073
Route	/admin/provider-connections plus create/detail family
Source screenshot	../screenshots/desktop/ui-009-provider-connections.png
Source page report	../page-reports/ui-009-provider-connections.md
Target sidecar	../target-images/target/provider-readiness-target.md
Primary persona	Provider administrator
Secondary personas	Workspace owner, support reviewer, security reviewer
Repo-truth posture	Source route and screenshot are repo-verified; target composition is direction only.

Current-State Snapshot

Provider Connections is the main integration authority. The report says it should make connection health, scope, credentials/consent state, and safe next action legible without exposing secrets or raw provider errors by default.

Current-State Productization Problems

• Health and permission readiness need stronger hierarchy than raw integration detail.
• Dangerous provider actions need confirmation and audit treatment.
• Provider-specific terms must not become platform-core truth.

Target User Promise

In five seconds, an admin knows whether the provider connection is ready, what permission or verification gap exists, and which safe next action resolves it.

First-Five-Seconds Target

Show provider readiness posture, target scope, missing permission or verification gap, last verification, and a single safe action.

Primary Decision

Is the provider connection ready for TenantPilot operations?

Primary Action

Resolve readiness gap.

Secondary Actions

Verify connection, review permissions, rotate credential, open diagnostics, create connection.

Target Information Hierarchy

1. Workspace-owned provider context.
2. Readiness posture.
3. Required permission or verification gap.
4. Safe next action.
5. Last verification and audit trace.
6. Diagnostics and raw provider detail.

Main-View Keep / Promote / Simplify

Treatment	Elements
Keep	Provider, connection type, target scope, health, permissions, last verification.
Promote	Readiness gap, safe next action, credential/consent boundary.
Simplify	Raw provider names as platform truth, secrets, raw errors, equal destructive actions.

Detail Drawer Treatment

Readiness drawer should show missing scope, affected TenantPilot capability, last verification, safe remediation path, and audit trace. Raw provider diagnostics stay secondary.

Advanced/Admin Treatment

Credential rotation, disconnect, disable, delete, and re-consent actions require capability-aware visibility, confirmation, audit, and recovery guidance.

Hidden/Removed Default Elements

Hide secrets, raw credential payloads, raw provider errors, tenant IDs, and debug-only claims from the first view.

Target Layout Direction

Use a readiness workbench: connection summary, permissions/gaps, safe action, verification history, and diagnostics drawer.

Visual Target Direction

Dark trust surface with warm panels, amber for missing permission, coral for disconnected/unsafe state, mint only for verified readiness, and no vendor-brand domination.

Status/Trust Model

Separate connection reachability, permission completeness, credential lifecycle, verification freshness, and TenantPilot capability readiness.

Dangerous Actions

Rotate credential, disconnect/disable, delete, and re-consent are high impact. Later implementation must include authorization, confirmation, audit, and redacted logging.

Customer-Safe Review Notes

Internal/operator surface. Customer-facing evidence can state readiness summary only, not secrets, raw scopes, or provider errors.

Workspace/Environment Context

Workspace ownership is explicit. Environment impact should be shown only when repo-verified.

Empty / Loading / Error States

Empty state should explain no provider connection exists and offer one setup action. Loading preserves workspace context. Error state separates TenantPilot validation failure from provider response failure.

Accessibility Notes

Readiness and permission gaps require text labels. Dangerous actions need clear modal headings and descriptions.

Repo-Truth Classification

Target element	Classification	Notes
Provider connection route and screenshot	repo-verified	Spec 323 browser pass reached the route.
ProviderConnection model	repo-verified	Existing model inventory includes it.
Permission readiness summary	plausible-existing	Must map to existing required permissions/contracts.
Capability impact copy	foundation-only	Constitution requires deterministic capabilities; exact mapping needs later spec.
Multi-provider neutrality in visuals	spec-only	Direction to avoid provider leakage.

Screenshot-Anchored Image Prompt

Start from ui-009-provider-connections.png. Create a target design direction, not runtime implementation. Preserve provider connection management. Show provider readiness, target scope, missing permission or verification gap, last verification, safe next action, audit trace, and collapsed diagnostics. Avoid exposing secrets. Avoid generic SaaS dashboards, fake compliance claims, green success without verification, placeholder text, raw provider errors by default, Microsoft-shaped platform-core claims, and runtime implementation claims.

Implementation Pattern Requirements

• Separate reachability, permission, credential, and verification state.
• Capability-aware next action.
• Dangerous provider actions confirmed, authorized, audited, and redacted.
• Provider-specific semantics stay bounded to provider-owned seams.

Later Implementation Candidate

Provider onboarding/readiness UX cleanup.

Non-Goals For Later Implementation

Do not create a generic provider framework or new provider taxonomy unless at least two real providers require it.