Work Flagship case study
A production-shaped case study for investigating SaaS revenue anomalies with cited evidence, auditable runs, and approval-gated actions.
Production teams need evidence, versioned tools, blocked risky actions, traces, cost, and regression checks - not only a confident summary.
Primary demo prompt: “MRR dropped this week. Investigate the cause, identify affected accounts, cite evidence, recommend actions, and draft follow-ups.”
Ledger is deliberately not a chat demo. It is a fixed investigation workflow plus a control plane that makes versions, tools, runs, approvals, and evals inspectable.
The investigation path is a fixed LangGraph DAG rather than open-ended tool thrashing. That keeps execution reconstructable: every run persists input, ordered steps, blocked calls, trace reference, model usage, final report, mock actions, and approval decisions.
Typical flow:
Failed runs stay visible. When a path ends without a final report, the failure and step trail remain inspectable instead of disappearing into a successful-looking summary.
Claims are expected to point back to retrieved evidence: SQL-derived metrics, tickets, product events, knowledge documents, or incident records. The UI exposes report citations alongside the step timeline so a reviewer can verify why a diagnosis exists.
Design rule: the evidence classifier / retrieved sources are the source of truth. An optional LLM may synthesize wording through a structured schema; it does not invent or override the supported conclusion.
The public demo path is meant to work without a paid model provider. Default configuration uses deterministic local diagnosis, local embeddings, and local trace identifiers. Provider-backed synthesis is optional and documented, not required for the core demo.
That choice is deliberate for transparent review: a reader can inspect behavior even when external model APIs are unavailable or undesirable.
Tools are registered with schemas and permission scopes. Published agent versions snapshot prompt, model, enabled tools, and allowed scopes. Risky customer-facing actions (Slack, email, CRM, task creation in the product model) remain mocks until an operator approves or rejects them.
Seeded scenarios double as regression tests. The good published version is compared against an intentionally degraded version so a reviewer can see a pass-rate drop and a specific failing case instead of trusting a single happy path.
From project verification notes (deterministic default path): good version
6/6, degraded version 5/6, with a flagged regression
such as eval_usage_drop_after_import_outage. Root-cause scoring on the
default path uses exact matching against deterministic diagnosis - reviewers should know
what is and is not being measured.
Status: planned / in progress for the public case study - not claimed as a live production Stripe integration on the public demo.
The intended boundary is narrow: Stripe test-mode is an evidence adapter that normalizes sandbox customers, subscriptions, and invoices into Ledger's existing billing model. Investigation logic stays outside Stripe. Signature verification, event idempotency, out-of-order handling, and reconciliation belong to the adapter, not to free-form agent improvisation.
Target public surface: ledger.leihuang.me. Topology follows Vercel (Next.js) + Render (API, worker, Postgres/pgvector, Redis-compatible storage). For an anonymous public deployment:
OPERATOR_UI_ENABLED=false)Honest demo note: treat the public deployment as a read-only evidence surface. Operator recording and mutating review happen in authenticated or local environments, never by leaking tokens into public client variables.