Sightspool has no data of its own. Everything it claims traces back to a source you connected, and every source is scoped to a single workspace. This page covers what you can connect, what each source contributes, and how credentials are handled.
What Sightspool can read
- PostHog — behavioural evidence. The register's signals run against your project, and it is the delivery channel when a study is better served by a survey you already own. It cannot establish causality or motivation.
- GitHub — structural evidence from the repository. Sightspool reads implemented flows and product change, re-arms assumptions a change threatens, and drafts new ones for surfaces nothing covers. Code cannot prove actual use, comprehension or value.
- Public product — provisional evidence from the unauthenticated URL supplied during onboarding. It can explain visible promises and entry points at n=0, but not signed-in tasks, actual behaviour or prevalence.
- Stripe — commercial context. Revenue and payment behaviour tell the agent which findings are expensive, not just which are true.
- The in-product SDK — first-party signals captured at the moment of friction (intent, effort, account), plus the delivery channel for approved interventions.
If your analytics provider is not natively supported, request an adapter from Connections. The request retains the exact client-approved product question, the capability it requires and the bounded read Sightspool needs; it does not invent a generic analytics requirement or silently swap the question.
How credentials are handled
Connector credentials are encrypted at rest with AES-256-GCM and resolved per workspace at runtime. They are read credentials: Sightspool reads your project, and the one exception is explicit — a PostHog key with survey-write scope, which you supply only if you want approved studies delivered through your own PostHog. The in-product SDK key is deliberately different: it is publishable, meant to be visible in your page source, and constrained by an origin allowlist you control.
Live, sample and off
Each source runs in one of three modes. Live reads your real project. Sample returns realistic mock data so you can explore the product before wiring anything up. Off leaves the source disconnected.
Sample data is explicitly marked as mock everywhere it appears, and the distinction is enforced rather than annotated: in production, a finding whose every cited source is mock is rejected before it can publish. You can explore with sample data as long as you like — it simply cannot become evidence.
Running the first read
Approve one product question on Overview and run the first read from there. Sightspool freezes the exact source contract, including each source's capability and limitation. A public URL or one relevant connected source can support the bounded read; an outcome, persona, journey, committed assumption and armed watch remain optional. After a completed first read, broad workspace analysis can inspect the wider source set and the background worker can advance queued tasks, check committed assumptions and report only what actually changed.