Sightspool builds a persistent, source-backed understanding of your product and turns it into tracked assumptions, cited findings and client-owned actions. This page takes you from your first sign-in to your own citable read.
1. Look around the demo workspace
Sightspool is currently in an open 30-day founding beta. Join at sightspool.com/login?mode=signup and you land in a demo workspace straight away — a fictional product with connected sources, findings that cite their evidence, a register entry that has been measured and refuted, and one that honestly reports it is still gathering. Nothing there is your data, and a standing banner says so. Click through it: the demo behaves like a real workspace, so anything you can do there you can do in your own.
2. Create your own workspace
When you have a real product question to bring, use Create your workspace in the demo banner. That asks for a workspace name and either a public product URL or one product question. Your founding-beta window and the senior UX review included with the cohort begin here, not when you signed up — so there is no cost to exploring the demo first. The demo stays in your workspace switcher and stays separate: no evidence, assumption or finding ever crosses between them.
3. Connect a source
On the Connections page, connect the source closest to your approved question. PostHog contributes observed behaviour; GitHub contributes structural implementation context; Stripe contributes relevant commercial state; and the Sightspool SDK contributes captured intent and effort. One relevant source is enough. If you supplied a public product URL, Sightspool can also begin with a provisional public-surface read at n=0.
4. Run the first product read
Approve one real product question on Overview. The first product read freezes that question and the sources it is allowed to use, then states the capability and limitation of that exact source set before returning a durable result: what Sightspool can prove, what it cannot say, the strongest alternative explanation, and one proposed action with its downside. Repository and public-product evidence is labelled structural or provisional, never behavioural proof. If the available sources cannot measure the question, Sightspool names one concrete next evidence action instead of sending you to a generic connector wall. Every metric or finding must cite the live tool call that produced it — no proof, no post.
5. Set the desired outcomes
The Outcomes page holds the meaningful changes this product is trying to create. A workspace can have many desired outcomes, with a small client-curated set kept in focus. Describe who or what should change, the change itself, the evidence that would count as success and any guardrail. Outcomes are not another signup gate, and Sightspool never marks one achieved merely because a linked assumption holds.
6. Own the Action and review the outcome
From a completed first read or cited finding, explicitly save accept, amend, challenge or dismiss. An accepted or amended Action records the change you intend to make, who owns it, the signal you expect and when you will review it. You later record your own implementation and the observed result with its limitations. Sightspool does not claim to execute the change, does not force challenge or dismiss toward implementation, and never turns a possible next question into approved intent automatically.
7. Work the register
The Assumptions page is the register: each entry is a belief made falsifiable — a question, a signal definition, a threshold, and a verdict with append-only history. Link an assumption to every desired outcome it helps test; one assumption can serve several outcomes. The agent drafts entries from your repo and your evidence; committing one is always your call. Committed entries go under watch: their signals run against your connected sources on a schedule, and below the minimum sample the register says "still gathering" — it never upgrades a thin read to a verdict.
8. Talk to the agent
Before your first durable read, Help → Sightspool Agent is the one agent entry so the current question and evidence path stay primary. After that read completes, the agent also becomes ambient through “Ask the agent”; the thing you're looking at — a register entry, a finding — pins itself as context. “Go deep” runs a full studio session that routes your question through research, interaction-design and service-design lenses and synthesises an answer. When the lenses disagree and no data settles it, the session escalates to a human instead of bluffing.
Where things live
- Navigation grows with the workspace: Start and one Help entry come first; areas with real workspace state appear when relevant; the full operating model returns after the first durable read.
- Overview — the signed-in home: what changed, what's waiting on you.
- Outcomes — the client-owned portfolio of meaningful changes, with a focused subset and linked assumptions.
- First read / Action — the current question's durable evidence handoff, explicit client decision, implementation record and observed-outcome review.
- Feed — proof-gated findings, with the cited evidence one click away.
- Assumptions — the register: beliefs, thresholds, verdicts, watch state.
- Interventions — approved research or customer-surface actions; not the client's delivery work.
- Connections — sources, the in-product SDK key, and coding-agent (MCP) access.