Skip to main content

Chapter 17: Lumen The Knowledge Graph and Outcome Tracking

Chapter 17: Lumen The Knowledge Graph and Outcome Tracking

The Knowledge Graph is Lumen's memory. When Supabase is connected, every decision, experiment, segment, metric, and governance event from every workflow run is persisted as a structured entity. Each entity links to the ones it relates to.

Without Supabase, Lumen is a one-session analysis tool. Supabase, it is a continuously improving PM operating system.

What Gets Stored

Every workflow run writes entities to the Knowledge Graph. The full schema has 15 entity types.

Entity

What it captures

Written by

UserSegment

Segment definition, PMF score, cohort

SignalMonitor, DiscoveryOS

Opportunity

Ranked opportunity, evidence, source interviews

DiscoveryOS

Persona

Customer persona derived from interviews

DiscoveryOS

Experiment

Hypothesis, sample size, success metric, results

HypothesisLab

Feature

Feature under validation, clearance status

DataLayer, DecideWell

Decision

Decision memo, options considered, outcome tracking ID

DecideWell

Metric

North Star definition, formula, target

NorthStar

MetricFormula

Machine-readable formula for each metric

NorthStar

Launch

Launch readiness score, go/no-go, execution plan

LaunchPad, OpsCommand

GovernanceEvent

Ethics clearance, approver, conditions

DataLayer

PricingBand

Pricing model, tier structure, scenarios

PriceLogic

EventTaxonomy

Validated event schema, compliance flags

EventIQ

TechDebtItem

Capacity constraints, blockers

RoadMap

RegulatoryConstraint

GDPR, HIPAA flags, DPA status

DataLayer, EventIQ

OrgNode

Team, OKR owner, capacity

NorthStar, OpsCommand

Entities connect through edges: validates, moves, informs, addresses, impacts, outcome_confirmed_by. A Decision entity connects to the Experiment that validated it. A UserSegment connects to the Opportunity it informs.

Outcome Tracking IDs

Every Decision entity gets an outcome tracking ID. This ID is the link between the decision and its result.

When DecideWell produces a decision memo, it writes an outcome_tracking_id to the Knowledge Graph. That ID looks like:

outcome-helix-w1-team-plan-recovery-20260313

Thirty days later, you re-run the relevant workflow. In your prompt, you include the outcome tracking ID:

/lumen:churn

Context: Follow-up on W1 PMF Discovery run from March 13.

Outcome tracking ID: outcome-helix-w1-team-plan-recovery-20260313

Key question: Did the roadmap-to-sprint handoff fix improve Team plan D30 retention?

              We targeted ≥68% D30 (from 61%). What does the current data show?

Lumen retrieves the decision baseline from the Knowledge Graph and compares the current PostHog data against it. The output is a delta report: what the target was, what the current state is, and whether the intervention is working.

This is how you close the PM feedback loop — not with a post-mortem slide, but with a structured outcome comparison against a committed prediction.

30/60/90-Day Review Rhythm

Every W2 (PMF Recovery) and W6 (Churn Analysis) run sets up 30/60/90-day outcome tracking automatically.

[LUMEN] Outcome tracking IDs:

  Day 30: outcome-helix-w6-churn-20260313-d30

  Day 60: outcome-helix-w6-churn-20260313-d60

  Day 90: outcome-helix-w6-churn-20260313-d90

  Add these to your calendar. On each date, run:

  /lumen:churn

  Provide the relevant tracking ID in your prompt context.

  Lumen will compare current NRR against today's baseline.

This is the most underused Lumen capability. Most teams do the first workflow run and move on. The outcome tracking IDs are the mechanism for accountability. If you committed to raising NRR from 89% to 100%, the Day 30 ID is how you measure whether you did it.

How the Knowledge Graph Improves Future Runs

The Knowledge Graph makes each subsequent workflow run better than the last.

Prior quarter context. When you run W3 Strategy in Q3, the Orchestrator reads your Q2 decision history from the Knowledge Graph. NarrativeEngine leads the executive update with the delta from last quarter. OpsCommand calibrates the leadership briefing to what the board already knows.

Experiment history. HypothesisLab reads prior experiment results when designing new tests. It will not design an experiment that has already been run and produced a result. It also uses prior MDE (minimum detectable effect) data to calibrate power calculations more accurately over time.

Churn fingerprints. GrowthIQ accumulates churn_cohort_fingerprint entities over time. This lets it identify pattern-matching between a new churn signal and a prior churn event. "This cohort looks like the March 2026 roadmap editor cohort" is a useful early warning.

Decision history. DecideWell reads prior decision memos before generating new ones. If the same decision has been faced and made before (e.g., "should we invest in Solo plan"), it surfaces the prior reasoning and asks whether the constraints have changed.

Data Security

All Supabase tables use Row Level Security scoped to workspace_id. Your Knowledge Graph data does not mix with any other workspace. Supabase handles encryption at rest.

The Anthropic API processes your prompts per normal Anthropic data handling policies. Lumen does not transmit Knowledge Graph data to any service other than Supabase.

If you need to delete specific entities from the Knowledge Graph, do so directly in your Supabase project dashboard. Lumen writes to the KG but does not have a built-in delete operation — entity deletion is a database-level action.