Genomströmning och affärssignaler

Maskinöversatt från engelska — källa: throughput-and-business-signals.md.

Implementeringsstatus: Designanteckning — implementerar visionsåtagande (d): "Exekvering kopplad direkt till affärssignaler. Budgetar och kassasaldo behandlade som systeminmatningar."

Byggt idag: SQLite-databasen på .compound-state/agent-service.db finns och fylls redan av Darwins befintliga loopar (schemaforskning, marknad, sammansatt nattligt). Formen på kostnad-per-PR-data fångas av genomströmnings-loggern som läser benchmark-körningar.

Mål-tillägg: pipeline_runs-tabellen som skissas nedan; per-PR-skrivningen som triggar vid merge; kassa-/intäkts-/burn-flödet in i orkestrerarens pre-flight-budgetkontroll; optimerings-matematikerns veckovisa läsning av rollupen. Inga av dessa skrivvägar finns ännu; inget producerar en summary.json per PR idag.

Två kopplade mätvärden driver den agentiska pipelinen:

• Funktioner per sekund per token — orkestrerarens effektivitet, använd av optimerings-matematikern för att tuna modellroutning.
• Affärssignaler (intäkter, kostnader, funnel, kassa) — begränsar hur aggressivt scale-or-kill rampar. Matematikern väljer modellroutning inom kassabudgeten, aldrig över den.

Funktioner per sekund per token

Definition

features_per_second_per_token = features_shipped / (elapsed_seconds × total_tokens_consumed)

Där:

• features_shipped = antal PR:er mergade som bär en docs/dossiers/-undermapp och en wiki/plans/-PRD-referens. Kosmetiska / hygien-PR:er räknas inte.
• elapsed_seconds = väggklock-tid över intaget + de åtta pipeline-stegen, per funktion.
• total_tokens_consumed = summan av input + output-tokens över alla modellanrop i pipelinen, per funktion.

Mätvärdet är medvetet litet i absolutvärde (10⁻⁹-skala). Det som spelar roll är trajektorin: trendar vi mot fler funktioner per token över tid? Flyttar specifika routning-ändringar siffran?

Var det loggas

Varje PR som mergas genom pipelinen skriver en rad till .compound-state/agent-service.db (sqlite) på Mac mini-servern:

CREATE TABLE pipeline_runs (
  id              INTEGER PRIMARY KEY,
  feature_slug    TEXT,
  spec_path       TEXT,
  pr_number       INTEGER,
  merged_at       TEXT,           -- ISO timestamp
  elapsed_seconds INTEGER,        -- stage 1 → stage 8
  tokens_total    INTEGER,
  cost_usd        REAL,
  features_per_second_per_token REAL,
  per_role_breakdown JSON         -- tokens + cost per role
);

Schemat är illustrativt — den faktiska tabellen bor i be-agent-service och utvecklas med pipelinen.

Vem läser det

Optimerings-matematiker-agenten (se agents-optimization.md) läser denna tabell på en veckokadens för att föreslå modellroutnings-rotationer. Inputs till dess förslag:

• Nuvarande routnings-matris.
• Per-rolls pass-andel, kostnad-per-mergad-PR, och 95:e-percentilens latens under föregående vecka.
• Publika benchmarkar: SWE-bench Verified pass@1, polyglot, osv.
• Kassabudget-utrymme från affärssignal-flödet.

Output: ett föreslaget justering till model-and-vendor-agnosticism.md:s routnings-matris, med en motivering grundad i datan ovan. CPO/CTO-ledningsagenten ratificerar eller avvisar.

Affärssignaler

Pipelinen är inte tillåten att optimera ren genomströmning isolerat — den måste respektera kassan. Visionsåtagande (d): budgetar och kassasaldo är systeminmatningar.

Inputs

Dessa flöden läses av orkestreraren innan varje dyr operation. Orkestreraren kan vägra att starta ett Architect-anrop om den projicerade pipeline-kostnaden skulle överskrida dagens budget.

Begränsningar härledda från signaler

daily_pipeline_budget_usd = monthly_pipeline_budget × (cash_runway_factor × revenue_growth_factor)

per_feature_budget_usd    = daily_pipeline_budget_usd / expected_features_today

Operationsordning:

1. CEO-ledningsagenten sätter monthly_pipeline_budget baserat på kassa + intäkter.
2. CPO/CTO-ledningsagenten allokerar det över pipeline-kostnad, scale-or-kill-ramper, och reserverad kapacitet.
3. Orkestreraren frågar efter den residuala dagliga budgeten innan varje pipeline-körning.
4. Matematikerns routnings-förslag är begränsade: föreslå aldrig en rotation som skulle skjuta förväntad per-funktion-kostnad över budgeten.

Vad "kopplad till affärssignaler" betyder konkret

Om intäkter accelererar → kassa-runway förlängs → daglig pipeline-budget växer → matematikern kan rotera till högre-kvalitets (= dyrare) rutter för Architect / Editor.

Om intäkter mjuknar → kassa-runway tajnar → daglig pipeline-budget krymper → matematikern roterar mot billigare rutter; aggressiv skalning pausar; icke-väsentliga pipeline-grenar (nattliga forsknings-lab-kampanjer) strypas.

Poängen med visionsåtagande (d) är att detta händer utan att en människa beslutar "ok, dra åt svångremmen". Signalen är inputen; svaret är mekaniskt.

Pilot-fas: budget-tillämpning är AV som standard

Runnern grindar kostnadstaks-tillämpning bakom PIPELINE_BUDGET_ENFORCEMENT (standard off). Kod på be-agent-service/apps/server/src/pipeline/budget.ts.

Varför av i pilot:

• En människa är den enda PRD-producenten och ratificerar varje PRD innan start — det finns ingen risk för rusande kostnad från externa/automatiserade PRD-producenter.
• Intäkter är noll; en intäkts-härledd daglig budget skulle också vara noll. Att tillämpa den skulle vägra allt arbete innan någon funktion levereras.
• Matematikerns routnings-förslags-kadens (veckovis) har ännu inte genomströmningsdata att läsa — runnern måste producera några mergade PR:er först.

Vänd på (PIPELINE_BUDGET_ENFORCEMENT=on, valfritt MAX_COST_PER_RUN_USD=...) när:

1. Flera människor (eller agenter) skapar PRD:er samtidigt.
2. Riktiga intäkts-/kassasignaler är kopplade till orkestrerarens pre-flight-kontroll.
3. Matematikern har minst 4–6 veckor av genomströmningsrader att basera routnings-beslut på.

Runnern loggar budget enforcement ON / budget enforcement OFF (pilot mode) vid varje körnings-start så operatörer ser tillståndet vid en blick.

Vad detta utesluter

• "Vi kör alltid Opus för Architect." → Nej. Architect kör vad routnings-matrisen säger, och routnings-matrisen är en funktion av affärssignaler.
• "Vi kör alltid lab-vågor på full kapacitet." → Nej. Lab-kapacitet skalar med budget-utrymme.
• Att spåra kostnad per roll isolerat. → Nej. Kostnad rullas upp till per-funktion, sedan per-dag, sedan jämförs med budget.

Vad detta tillåter

• Auto-strypning när kassan blir tajt, utan att en människa beslutar när "tajt" börjar.
• Auto-expansion när tillväxten är bra, utan att vänta på en kvartalsöversikt för att höja taket.
• Per-funktions-kostnadstak (vetar pipelinen innan den startar om specen är för ambitiös för dagens budget).
• Ett enskilt, auditerbart spår: varje routnings-beslut pekar tillbaka till en budget-beräkning som pekar tillbaka till en kassasaldo-läsning.

Korsreferenser

• Vision och mandat — åtagande (d).
• Modell- och leverantörsoberoende — routnings-matrisen detta styr.
• Skala eller stäng av — använder kassa-budget-inputen för att grinda rampar.
• Optimerings-matematiker — konsumerar genomströmningsraderna; föreslår routnings-ändringar.
• Ledningsagenter — ceo, cpo-cto, cmo-cso — äger budget-allokeringen.