SignalLake Documentation

Start with a workspace

A SignalLake workspace contains sources, models, metrics, dashboards, alerts, and access rules for one business unit or tenant.

Create one workspace for each reporting boundary. Most companies start with Revenue, Product, and Customer Operations. Keep the boundary close to how decisions are made: if two teams approve metrics separately, give them separate workspaces and share only the metrics they both need.

Use short workspace keys because they appear in API paths, export names, and audit logs.

curl https://api.signallake.test/v1/workspaces \
  -H "Authorization: Bearer sk_test" \
  -H "Content-Type: application/json" \
  -d '{"key":"revenue","name":"Revenue","region":"eu-central-1","timezone":"Europe/Berlin"}'

Workspace settings

Setting
Recommended start
Reason
key
A short team name
Keeps API paths and audit entries readable
region
Closest regulated region
Keeps data residency decisions explicit
timezone
Review team timezone
Aligns freshness and scheduled exports
retention
90 days for launch
Limits early storage while definitions settle

Examples

Business documents and charts used to define governed metrics

Metric contract example

Define ownership, source, grain, freshness, approval, and review policy in one record. Use this when a number is reused across dashboards or reported outside the team.

Open metric contract example

Data workspace with dashboards and charts

Dashboard publish example

Publish a governed dashboard for a review cycle without copying the underlying data. Use this when a live page should stay stable for a named audience.

Open dashboard publish example

Connect sources

Server infrastructure for real-time analytics

SignalLake reads from warehouses, application databases, event streams, spreadsheets, and billing systems.

Each source has an owner, a refresh policy, and a failure rule. The platform records those details so dashboards can show whether a number is ready for use.

For a first rollout, connect the system of record before enrichment sources. A revenue workspace usually starts with billing, CRM, and warehouse tables, then adds product events once the approved revenue number is stable.

Source policy examples

Source
Refresh policy
Failure rule
Billing export
Every 4 hours
Hold finance dashboards if older than 24 hours
CRM opportunity stream
Every 15 minutes
Warn pipeline dashboards after 1 hour
Product events
Hourly warehouse rollup
Show cohort views with last complete hour
Spreadsheet upload
Manual with owner approval
Mark draft until reviewed

Define metrics

Metric fields

Field
Purpose
Example
name
Human-readable label
Net revenue retention
source
Warehouse table or stream
finance.nrr_monthly
grain
Lowest valid reporting level
account_month
freshness
Maximum accepted age
24h
owner
Approver for definition changes
Revenue Operations
policy
Change rule for the metric
Finance approval required
audience
Where the metric may be published
Executive review, board packet
select
  account_id,
  month,
  recurring_revenue,
  expansion_revenue,
  contraction_revenue,
  churned_revenue
from warehouse.finance.account_revenue
where month >= date_trunc('month', current_date) - interval '12 months'
  and recognition_status = 'approved';

Publish safely

Publishing a dashboard does not copy data into a presentation layer. SignalLake keeps the dashboard connected to governed metrics, then applies permissions when a reader opens the page.

Use scheduled reviews for board packs and live links for operating reviews. Before publishing, check that every visible metric has an owner, an approved source, a freshness policy, and a reader-facing stale-state message.