Dwight

onboarding lab

See what Dwight would do with your week. No sign-in.

Readiness

Operational

96/100

1. New user setup

Pick the kind of user and where their work lives.

Persona

Where does your work live?

Choose places with ideas, drafts, conversations, decisions, documents, and work in progress.

time

people

artifacts

thinking

delivery

Background refresh

2. What Dwight starts for the user

Dwight can make a useful first matrix and explain its blind spots.

Updated

Connected sources

Calendar, Email, Drive, Notes, AI

Blind spots

Next: Chat

Cron model

2/day

Good default for v1

Protect

Protect one real work block for the main project

86%

Drive shows active project material, but calendar has not reserved a work block.

calendardrive

Do Now

Nothing Dwight can justify here.

Ignore

Do not reopen the loose idea backlog today

80%

Thinking spaces contain useful material, but no current deadline, waiting person, trust risk, or protected output.

notesai workspaces

Respond

Clear the one thread where someone is waiting

84%

Email shows a reply dependency and Drive gives enough project context to avoid a generic answer.

emaildrive

Narrow agent doctrine

What Dwight is allowed to become.

Move toward protected work

Every session should clear reactive fires fast so the path to deeper, compounding work stays open.

Protect compounding work

Strategic work gets defended before the day turns into replies and admin.

Reduce fake urgency

New, loud, and unread are signals, not instructions.

Keep trust rails intact

Client obligations, billing gaps, and delivery risks stay visible without turning the matrix into operations noise.

Approval for consequence

Dwight can draft, stage, repair, and prepare; consequential external actions wait for approval.

Blind spots

Dwight should say these out loud.

1Dwight cannot see assigned delivery systems like Linear, Jira, Asana, or GitHub.

2Dwight cannot compare the plan against actual time spent.

3Local Word documents, PDFs, and desktop folders are invisible unless imported or pasted.

Next connection

Chat and team messages

Requests, decisions, loose promises, people blocked on the user.

3. How it works under the hood

Optional — Supabase tables, cron jobs, and the learning loop.

▾

Request trace

1. Account created

browser

User lands on dwightmatrix.com, signs in, and reaches the access chooser.

writesNextAuth session cookie

2. Access choices saved

server

The onboarding choices become a user settings row and define which connector scopes Dwight requests.

writesgoals: onboarding/settings content, dwight_events: onboarding_access_selected

3. OAuth and imports

server

Connected SaaS sources write tokens or imported context. Pasted/local sources write recall records instead of long-lived tokens.

writesgoals: onboarding source preferences, google_tokens, notes_cache or dwight_recall, dwight_recall

4. Aggregate

server

/api/aggregate pulls connected sources in parallel and records connector health.

readsCalendar, Email, Drive and documents, Notes and thinking spaces, AI workspaces

writesraw source snapshot in memory for scoring

5. Score

dwight

/api/score sends the aggregate, goals, source health, and recall snippets to the scoring model.

readsgoals, dwight_recall, dwight_events, latest source snapshot

writesmatrix_cache

6. First matrix

browser

The user sees a matrix, confidence, blind spots, and the next source worth connecting.

readsmatrix_cache

7. Background refresh

cron

A scheduled job posts to /api/refresh so Dwight stays useful even when the user does not press Refresh.

readsgoogle_tokens, stored connector settings

writesmatrix_cache, dwight_actions when monitors stage recommendations

8. Learning loop

supabase

Done, dismissed, moved, snoozed, and corrected cards become behavioral memory for later scoring.

writesdwight_events, dwight_actions

Supabase cells

artifacts

Tracks generated docs, drafts, calendar blocks, and imported files.

First connector-specific ingestion.

dwight_commitments

Normalizes promises, waiting-on-human loops, and open commitments.

First connector-specific ingestion.

dwight_events

Stores user outcomes: done, dismissed, moved, snoozed, corrected.

Onboarding selected, then user outcomes.

dwight_recall

Stores pasted/imported work context for semantic recall.

Paste/import from notes, AI workspace, chat, or local file.

dwight_workspaces

Groups documents, artifacts, and card workbench state.

First connector-specific ingestion.

goals

Stores onboarding preferences, goals, and later the user-level Dwight settings.

Access chooser submit.

google_tokens

Stores OAuth tokens by account so server jobs can refresh without the browser open.

OAuth callback or first authenticated page load.

matrix_cache

Stores the scored matrix, source snapshot, goals snapshot, and connector health.

First /api/refresh or /api/score run.

notes_cache

Stores imported Apple Notes or notes bridge content.

Notes bridge or import job.

Cron jobs

Morning plan

08:00 local time

/api/refresh

Build the first useful matrix before work starts.

Midday recalibration

13:00 local time

/api/refresh

Compare the morning plan with live reality and re-rank.

Real-world notes

The first run should be called a simulation until the user has real connector data.

Every source should have a visible confidence effect. Missing data is not failure; it is a declared blind spot.

Drive and documents are the default artifact layer for most new users, not Toggl or Timing.

Chatbot and local-file work should start as paste/import flows before native connectors exist.

Time tracking remains optional. It improves calibration but should never be required for onboarding.

Like what you see? Run it on your own week.

Try Dwight for real →