User Journey

Stage 1 — Enter: Sign in through OneAuth

The user arrives through the single controlled entry — OneAuth — not an app-specific login.

• User does: authenticates once (or arrives with a delegated host session).
• System does: resolves identity → tenant → workspace → roles → entitlements → policies, and establishes entry context.
• Underneath: if IntegrateWise runs inside a host, OneAuth verifies the delegated identity; the host owns the session either way.

Stage 2 — Discover: See what the ecosystem already offers

IntegrateWise discovers what the host already has connected — it does not ask the user to reconnect Salesforce, Slack, or GitHub.

• User does: reviews the connections and capabilities available to their workspace.
• System does: Discovery enumerates host-connected apps, available connectors, readable data, tools, and models.
• Underneath: Capability Resolver intersects everything discovered against tenant policy, role, and context — surfacing only what this user can actually do.

Stage 3 — Connect: Host connections become governed projections

Each host-owned connection becomes a narrow connector projection — never a copy of the provider credential.

• User does: approves any connections that need explicit consent; reviews scopes.
• System does: creates a connector projection per connection — permitted scopes, resources, operations, read/write boundaries, approval requirements, retention, revocation state.
• Underneath: one connection fans out into read / sync / Twin-search / approved-write projections without duplicating the credential.

Stages 4–5 — Load & Normalize: Records become canonical entities

The Loader pulls permitted records; the Normalizer turns provider-specific shapes into canonical Spine entities and relationships. This is where the workspace stops being a set of tools and starts being connected truth.

• User does: watches hydration progress — loading accounts, resolving Slack-to-account relationships, indexing documents. Can continue in the background.
• System does: Loader → Normalizer → Pipeline → Operational Spine (D1) → canonical promotion / reconciliation (Neon) → cache invalidation → re-embed.
• Underneath: different apps surface different entities, all linked to the same canonical record — e.g. a billing record auto-links its Stripe, QuickBooks, and Razorpay sources with no manual marking.

Stage 6 — Activate: Reach a known readiness state

The Activation Hub converts an authenticated organization into an operational workspace by walking seven readiness gates in order.

An Activation Blocker (incomplete auth, missing connector, insufficient scopes, unresolved mapping, no admin, missing policy, failed pipeline) halts go-live until cleared. The Twin explains what's happening, why a step is blocked, and what value unlocks after completion.

Stage 7 — Work

The user opens their role-routed workspace — the same five-zone shell every department shares, filled with their data.

Land in the Workbench

• Header: Continuity Score, last sync, time + owner filters that cascade below.
• Pulse Bar: four live KPI cards; click one to filter the work surface.
• Work Surface: Table / Board / Calendar with inline capability buttons on every row — act without navigating away.
• OODA Action Bar: Observe, Orient, Decide (n pending), Act — fixed at the bottom.

Start the day in My Work

Home is a living brief, not a dashboard. It assembles priorities, blockers, decisions needed, interrupted continuity threads, and the first three suggested actions — plus anything that degraded overnight (connector failures, SLA breaches, deal-risk changes).

The Inbox renders intelligence, not raw messages: the Spine has already extracted entities mentioned, actions required, sentiment, and linked accounts from every message.

Invoke the Twin on a specific item

Stage 8 — The Loop

Propose → Govern → Execute → Reconcile → Learn

This is the steady-state loop the user lives in — and the reason the workspace organizes itself over time.

• Propose: Twin assembles evidence and recommends a task, doc, update, or action — with the evidence behind it shown.
• Govern: policy evaluates permissions, risk class (R0–R4), approval need, and expected effects. Nothing consequential runs without a human decision.
• Execute: on approval, the Orchestrator invokes the governed Tool Capability; the connector writes back to the source system.
• Reconcile: results return to the Spine, Views, Docs, and the audit ledger — tagged origin, confidence, approved_by. Provenance is immutable.
• Learn: approved / adjusted / rejected outcomes update governed Memory, sharpening future proposals.

Continuity across sessions

Work never restarts from zero. When the user returns, interrupted continuity threads resurface with the last meaningful event, the pending continuation, and the owner — so a paused deployment or half-finished QBR picks up exactly where it stopped.

Nothing is forgotten, context follows the work.