North star — strategy, positioning, North Star Metric
Brief section 11. Internal product, ~2 human readers + an agent fleet — standard commercial-strategy sections (pricing, funnel, churn) are N/A and compressed per README scope note, not fabricated. This doc does not re-litigate build/no-build (that’s
00-SYNTHESIS.md+11-build-vs-buy.md); it answers what work-ledger is for, who it’s for first, what it will never become, and the one number that governs it.
1. Vision / mission (one line each, internal-scale)
- Vision: every unit of the legacy rebuild has exactly one trustworthy record of what happened to it, who paid for it, and why — readable months after Temporal has forgotten it ever ran.
- Mission: give Robert’s agent fleet a place to atomically claim work and durably record its outcome, so cost and disposition survive Temporal’s retention window and can be read at kill gates without doubt.
Both sentences are direct restatements of 01-initial-recommendation.md’s framing (“An accounting system, not an app” / “no unit of work can be in an ambiguous state”) — that framing survived every research pass (competitive, priorArt, temporalCase, repoRecon digests) unchanged, so vision/mission carry forward rather than reinvent.
2. Positioning statement
Using the standard template as an internal-alignment tool, not a marketing artifact:
For agent fleets executing audited legacy-rebuild units (beachhead: Robert’s fleet, Orders flagship, 10→64 concurrent), work-ledger is the durable business-fact record of the rebuild program that gives every unit exactly one claimant, one disposition, and one attributed cost — queryable months after Temporal purges the execution history. Unlike Temporal visibility (72h retention, 28-attribute filter index, purged at close — temporalCase digest B1/B2), beads (Dolt-backed claim tool with open multi-machine consistency bugs and a Postgres-backend build-then-rollback 2 days before this research, 2026-07-16 — priorArt/oss digests), or Linear/GitHub Issues/Jira (assignee-field races, no disposition taxonomy, wrong vocabulary — competitive digest §a–b), work-ledger is a Postgres-enforced accounting system, not a work-tracking app, and it never claims to be execution truth.
3. ICP — who this is for
| Tier | Who | Relationship | v1 commitment |
|---|---|---|---|
| Beachhead (primary) | Robert’s agent fleet, Orders domain flagship, 10→64 concurrent Claude sessions | Write-path user via external-claim endpoint (v1 reality — units are not yet Temporal workflows, repoRecon digest) | Yes — the only write-path user v1 is built for |
| Operator | Robert | Read path: queue depth, stall detection, cost/merged-unit, rework rate | Yes — via Grafana/SQL, no bespoke UI |
| Stakeholder | Tomas Zaruba | Read-only, low-frequency, high-stakes: disposition table at kill gates (M4/M8/M12) | Yes — read access only, zero write coupling |
| Expansion (not v1) | Tomas’s own fleet, if/when domain-migration units are claimed through work-ledger | Untested prior: “dispositions alone justify single-fleet ownership” (open question #3, 01-initial-recommendation.md) |
No — upside, not a requirement |
| Expansion (not v1) | Old-estate 1→N Encore split lane | v3 per 00-SYNTHESIS.md evolution path, gated on “ledger >500 units” |
No |
| Explicitly not ICP | Any team outside the rebuild program; generic PM users; any commercial customer | — | N/A — internal-only, no market exists for this category (competitive digest: no vendor sells “AI-fleet work ledger” in 2026) |
4. Differentiation
No competitor exists in the commercial sense — the differentiation question is really “why not adopt X instead of building.” Answered rigorously across four research passes; summarized:
| Alternative | What it actually gives you | Where it structurally fails work-ledger’s requirement bundle | Source |
|---|---|---|---|
| Temporal visibility (search attributes) | Native atomic claim via workflow-id uniqueness; live state filter | 72h retention purges disposition/cost/evidence within days — kill gates are months out. Archival = replay-only blobs, not a queryable table. 28-attribute cap (10 Keyword + 3 each of Bool/Datetime/Double/Int/KeywordList/Text — oss digest corroborates “3 custom numeric attributes/namespace”), 2KB/255-char value caps. No unit-workflow exists for v1’s external-session fleet (repoRecon: only one toy workflow on the internal-plane substrate — the stream work-ledger would project from — exists; Core’s merchant-contract-signing runs on Core’s own workers, irrelevant to the projection point). | temporalCase digest B1–B3 |
| beads (Dolt-backed claim/dependency tool) | Actor ownership, hash-based IDs avoiding sequence collision across branches | Open, unresolved multi-machine merge conflicts on its own metadata table (issues #2466, #2765), zero chaos-test coverage on the Dolt backend, and its own Postgres backend was built then rolled back 2 days before this research (2026-07-16) — the tool is thrashing on its own storage layer | priorArt digest §2; oss digest verdict input |
| Linear (incl. Symphony pattern) | Well-designed AgentSession lifecycle; OpenAI’s own Symphony proved poll-and-dispatch on Linear ships 500% more PRs with zero new service |
No atomic claim (optimistic assignee-field write, not compare-and-swap — exactly the failure mode locks-only reproduces at highest rate per the June-2026 arXiv preprint); no cost-per-unit field; no disposition taxonomy — terminal state is just done_state. OpenAI explicitly declined to productize it. |
competitive digest §b |
| GitHub Issues / Jira | Ubiquitous, human-familiar | Documented 2026 rate-limit crisis under agentic load (5,000 req/hr shared across 4 code paths, 8.4× overrun observed) — a rate-limited SaaS API is the wrong substrate for a 64-concurrent atomic-claim primitive. Jira’s failure mode is upstream (vague epics, no clarifying-question channel) — wrong problem entirely. Both also collide with this program’s vocabulary ban (“ticket” is forbidden). | competitive digest §b |
Process only (ADRs + Temporal + tasks svc, no new table) |
Covers ~30% of the SoR mandate for zero build; component-tier dispositions genuinely belong in the existing append-only ADR log, not a table | Fails at unit-tier cardinality (~1000 units vs ~26 components) and fails the same retention wall as Temporal-native, since it still needs somewhere durable to hold cost/disposition — that somewhere is one Postgres table either way | temporalCase digest (full “DO NOT BUILD” stress-test) |
Net differentiation claim: work-ledger is the only candidate that is simultaneously (a) durable past 72h, (b) has a real disposition taxonomy backed by evidence, (c) attributes cost per unit, and (d) is DB-enforced rather than convention-enforced at claim time. Every alternative gets at most 2 of 4.
5. Moat
N/A — commercial moat doesn’t apply; internal system, no market, no competitors to lock out. The internal equivalent: trust accumulated in an append-only, evidence-linked record. Once Tomas has read three kill gates off work-ledger’s disposition table and it has never once disagreed with what actually happened, replacing it costs the credibility built, not the migration effort (the table itself is trivial to re-create — that’s the whole BUILD THIN thesis). This is the internal-system analog of a data moat, and it is independently articulated outside this program: Paul Gross’s “ledgers-as-primitive” framing (pgrs.net, 2025-06-17, cited in competitive digest) makes the identical argument for ledgers generally — durable value lives in the data model + invariants, not the wrapper.
This moat is asymmetric and fragile, not durable by default. It is built one clean reconciliation audit at a time and destroyed by a single caught discrepancy (00-SYNTHESIS.md pre-mortem #3: “first reconciliation mismatch… trust in both collapsed”). That asymmetry is why the reliability and retention-equivalent metrics below (§7) exist as first-class numbers, not afterthoughts — they are the moat-preservation mechanism, not generic SLOs.
6. Strategic non-goals
| Non-goal | Why | Escape hatch (if ever revisited) |
|---|---|---|
| No UI product | Grafana + SQL is the entire human surface; a screen is scope creep toward “worse Linear” | Only if ≥3 humans need the disposition view interactively — then one server-rendered table, not an app (01-initial-recommendation.md platform verdict) |
| No second tenant required | Tomas’s fleet adopting work-ledger is upside, not a v1 dependency — open question #3 stays untested by design | Revisit when/if Tomas’s fleet starts claiming domain-migration units |
| No PM-tool ambitions | No priorities, sprints, comments, notifications, assignee routing — every commercial “AI work board” that shipped this shape (Vibe Kanban/Bloop, Terragon) is now defunct as a business (competitive digest §a, priorArt digest table) | Never — this is a category-error risk, not a roadmap item |
| No core-plane coupling | v1 is zero-PR against Tomas’s core plane (external-claim endpoint + internal-plane-only tables) | Any future ask (e.g., a tasks TaskType PR) stays a single, explicit, negotiated PR — never implicit coupling |
| Never execution truth | Temporal is the only execution truth, permanently. work-ledger is a one-way projection plus business fields Temporal itself purges (disposition, cost, attempts, evidence link, blocking-question ref) — not a parallel state machine that could disagree with Temporal | Never — this is the load-bearing invariant 00-SYNTHESIS.md pre-mortem #3 and the temporalCase digest both converge on. The correction that digest forces: work-ledger should be thinner than plan 001, not thicker — own only what Temporal can’t keep, not a mirrored lifecycle engine |
7. North Star Metric
7.1 The metric
Verified throughput — work units per week reaching a terminal disposition (MIGRATED | DROPPED | DEFERRED | DEAD) with both cost and evidence_url populated:
verified_throughput(week) = COUNT(units WHERE disposed_at ∈ week
AND disposition IS NOT NULL
AND cost IS NOT NULL
AND evidence_url IS NOT NULL)disposed_at is denormalized from the disposed event (10-architecture.md §3).
Reported as a rate (per trailing 7 days), not a cumulative stock — a stock number only ever goes up and hides regressions.
Why this metric and not something more familiar: it is a direct operationalization of §1’s problem statement — “no unit of work can be in an ambiguous state.” An ambiguous unit is one still open, or closed without cost/evidence. Verified throughput counts exactly the transitions that remove ambiguity and leave a trustworthy trail behind. All four dispositions count equally: a correctly-diagnosed DEAD unit is as much real progress as a MIGRATED one — both replace ambiguity with an accountable answer. This is the one place the metric and the product’s stated purpose are the same sentence, which is the strongest evidence it’s the right number, not a proxy for the right number.
Known gaming risk, named and mitigated: DEFERRED is the cheapest disposition to assign (defer = decide nothing), so a naive read of verified throughput can be inflated by deferring instead of resolving. Mitigation: report disposition mix alongside the headline number (stacked, not blended) and treat a rising DEFERRED share as a smell test on the metric itself — threshold TBD from the first 4 weeks of real data, not invented here to avoid fabricating a number with no baseline.
7.2 Alternatives considered and rejected
| Candidate | Formula | Why it loses | Verdict |
|---|---|---|---|
| Total units claimed | COUNT(claims) |
Gameable by claiming alone — an agent can claim 100 units and finish zero; the number rises with zero value delivered. Literally the anti-metric named in §8. | Rejected — vanity metric |
| Ledger coverage % of fleet work | claimed_via_ledger / total_fleet_work |
Real signal, but it’s an adoption/compliance floor, not a value metric — 100% coverage with zero verified units is still total failure. | Kept as a guardrail, not the North Star |
| Questions per unit | blocking_questions / units |
Wrong owner: this is question-triage’s health metric (dedup effectiveness, stakeholder-overload — plan 001 per-app verdict #2), not work-ledger’s. Low questions/unit is ambiguous — could mean triage works, or could mean the ledger data is too sparse to trigger blocking (false efficiency). | Rejected — belongs to a sibling app |
| Cost per verified unit | Σcost / verified_units |
Legitimate efficiency signal, but inverted (lower is “better,” which doesn’t map to “we created more value”) and gameable by rushing verification to cut cost per unit while total throughput stagnates. Correct role: paired guardrail against rework rate, never the headline. | Kept as a guardrail pairing, not the North Star |
No candidate beats verified throughput on the standard NSM test (reflects real value delivered, resistant to gaming in isolation, leading not lagging, single legible number, directly actionable by the two humans who read it).
8. Full metric taxonomy
| Category | Metric | Definition | Role |
|---|---|---|---|
| North Star | Verified throughput | §7.1 | The number Robert and Tomas track weekly; gates concurrency ramp (§9) |
| Activation | First agent-claimed unit | Fleet-wide: timestamp of the very first successful claim() call — marks v1 actually live, not just deployed. Per-agent: each new agent identity’s first successful claim (no double-claim rejection) — the agent-scale equivalent of “aha moment,” expected near-instant since this is an API, not an onboarding flow. Not to be conflated with 04-user-stories.md US-00 (first unit claim→verified end-to-end) — that’s a separate end-to-end proof gate, not this activation metric |
Go-live signal + per-agent onboarding health |
| Time-to-value | Median cycle time | median(disposed_at − claimed_at) per unit |
Should trend down as throughput trends up — complementary axis, not the same axis; stall detection (fleet monitor) is the leading indicator that feeds this |
| Engagement | Daily claiming agents | Distinct agent IDs issuing ≥1 claim() per day |
Fleet-utilization signal; falling while headcount is flat = agents working unlogged (coverage guardrail catches this from the other side) |
| Retention-equivalent | Weekly reconciliation audit pass rate | % of a sampled set of verified-disposition units whose cost + evidence + disposition survive an independent spot re-check without discrepancy |
This is work-ledger’s trust metric — the behavioral analog of retention: if the data can’t be trusted, its two human readers stop consulting it, which is functionally churn for a system with two users. Directly operationalizes 00-SYNTHESIS.md pre-mortem #3’s detection signal |
| Quality | Rework rate | % of units with attempts > 1, or verified units later reopened/reclaimed |
Named explicitly across plan 001 as the fleet monitor’s thin-layer computation; work-ledger supplies the raw attempts/reopen data it’s computed from |
| Reliability | Claim endpoint p99 + zero double-claims | p99 latency as a standard SLO; double-claim count as a hard-zero correctness invariant, not a percentage target | Double-claims aren’t a tolerance band — one occurrence is a proof the atomicity guarantee failed and should stop the ramp (§9), full stop |
| Guardrails | Claim-to-verified conversion rate | % of claimed units that eventually reach a terminal disposition vs. abandoned/stuck in limbo | Floor — prevents “grow the North Star by ignoring health” |
| Stale-claim rate | % of claims exceeding timeout with no heartbeat/transition | Leading indicator of dead agents holding locks — rising with concurrency is an early collision-risk signal, independent of rework rate | |
| Ledger coverage % of fleet work | §7.2 | Floor — verified throughput is meaningless if most fleet work never enters the ledger at all | |
| Anti-metrics | Units claimed but never transitioned (“ledger theater”) | claim() called, no transition()/block() follows within SLA window |
Directly measures fake engagement — the claim-only version of vanity signups |
| Row count growth without dispositions | Total ledger rows rising while disposition-bearing rows stay flat | The ledger’s version of “more signups, no revenue” — growth in the wrong dimension |
9. Ramp-gating connection — concurrency unlocked by these metrics, not the calendar
Robert’s fleet ramps 10 → 50 → 64 concurrent agents. 00-SYNTHESIS.md already names this as a high-likelihood-if-ignored risk (“fleet sized beyond evidence”); this section makes the gate mechanical, sourced in these metrics, not vibes.
flowchart LR A[10 concurrent<br/>v1 baseline] -->|verified throughput ↑ 2wk<br/>AND rework rate flat/↓<br/>AND zero double-claims<br/>AND conversion ≥ floor| B[50 concurrent] B -->|same 4 conditions<br/>sustained 2wk at 50<br/>AND stale-claim rate not rising| C[64 concurrent — ceiling] C -.->|nothing published past 64,<br/>Bun migration is the ceiling case E9| D[beyond 64: not attempted<br/>1000 = queued units,<br/>never concurrent editors]
| Step | Unlock condition (all must hold, metric-sourced) | If violated |
|---|---|---|
| 10 → 50 | Verified throughput trending up ≥2 consecutive weeks at 10-concurrent, rework rate flat or falling, zero double-claim incidents, claim-to-verified conversion at or above the guardrail floor (threshold set from first 4 weeks of real data) | Hold at 10; investigate whichever guardrail broke before adding agents |
| 50 → 64 | Same four conditions sustained ≥2 weeks at 50-concurrent, plus stale-claim rate not rising with concurrency (early signal that claims are outrunning review capacity) | Hold at 50 |
| Past 64 | Not attempted. [E9]: nothing published validates orchestration beyond 64 concurrent; the best comparable case (Bun migration) proved exactly 64 concurrent with 19 escaped regressions and a 53.9% tangling base rate. 00-SYNTHESIS.md’s own framing: “1000 = queued units, never concurrent editors” |
N/A — hard ceiling by evidence, not policy |
Explicit non-ownership: review capacity is the fleet’s real ceiling independent of concurrency (research/12 §1.7: AI-authored PRs wait 4.6× longer for review, 32.7% acceptance — independently corroborated by OpenAI’s Symphony finding that a 5× PR increase just moves the bottleneck to review, competitive digest §b). Work-ledger does not own a review-capacity metric; it supplies the verified-throughput numerator the fleet monitor’s review-capacity denominator gets divided into. Ramp decisions are made by whoever owns the ramp (Robert), reading both.
Cross-references
| Doc | What it owns that this doc doesn’t |
|---|---|
00-SYNTHESIS.md |
The build/no-build decision this strategy assumes |
01-initial-recommendation.md |
Source of the vision/mission framing carried forward unchanged |
05-competitive-analysis.md |
Full vendor-by-vendor detail behind §4’s table |
06-open-source-analysis.md |
Full beads/pgmq/graphile-worker verdicts behind §4’s beads row |
10-architecture.md |
The actual schema (disposition enum, cost column, evidence_url) this metric taxonomy reads from |
13-pre-mortem.md |
Full failure-mode detail behind §5’s moat-fragility claim and §8’s retention-equivalent metric |