ADR-039: Decision capture primitive — extend Sync beyond game scenarios

Status: Proposed Date: 2026-05-05 Context: Sync today only ingests data from game scenarios (solo, multiplayer, campaign). Real org decisions — the "should we keep Cici on reskin or pause for connector?" kind that happen in meetings, chat threads, and agent calls — are invisible to the trust graph. James (May 4 all-hands) reframed Sync as the "mother algorithm" / coordination substrate the Beacon white paper described, where decisions outside the game should also flow through Sync, get captured, and update trust weights. The current code is well-positioned to be that substrate but is missing the primitive that captures non-game decisions.

At a glance

What it decides: a proposal (not yet in force) for a decision_log primitive that pulls real org/team decisions — not just game scenarios — into Sync, so the trust graph can learn from how people actually decide.

• Core mechanism — capture decisions passively (transcripts now, agent calls and in-channel later), then a 14-day "worked / didn't / mixed" outcome tag turns them into trust signal.
• Phased — only Phase 1 (transcript ingestion + outcome tagging) ships now; agent-call and in-channel capture are deferred until Phase 1 proves useful.
• Main rejected alternative — building James's full ZHC closed-loop coordination layer up front; this ships the smallest testable unit instead.
• Cost/risk — without outcome tags the data is just noise; trust depends on people actually tagging outcomes (target ≥40% at 14 days).
• Open question — how a captured decision should reweight existing judgment-layer signals (held until there's enough data to decide empirically).

Decision

Introduce a decision_log primitive that captures real decisions (not game scenarios) into Sync, with three progressive ingestion layers and a paired outcome-tagging mechanism. Phase 1 ships transcript ingestion and outcome tagging only; Phases 2–3 are deferred until Phase 1 data proves useful.

Schema:

decision_log:
  id, source ('transcript' | 'agent' | 'manual'),
  source_ref (meeting URL, MCP request_id, etc),
  question_text, context_text, options_jsonb,
  decision_text, decided_at,
  outcome_text, outcome_rating ('worked'|'didnt'|'mixed'|null),
  outcome_at, linked_signals_jsonb

decision_participants:
  decision_id, user_id, stance, weight

Three ingestion layers:

1. Transcript ingestion (Phase 1, ship-this-month). Fathom (or pasted) transcripts → LLM extraction pass → decision_log rows. No new product UI required for capture; just a pipeline. Two transcript sources, both Phase 1:
2. Org meetings (all-hands, 1:1s) — the original framing.
3. Post-game discussions (added May 5 after Cici's observation that the 30-min conversation after a 5-min scenario reveals values, context, and reasoning that the choice-only data misses). The Fathom transcript of a multiplayer game session is high-density signal — rationale + cross-talk + mind-changes — and feeds the same decision_log pipeline. CoachJ explicitly endorsed this on the May 5 call: "Hermes is taking in all the transcripts of the multiplayer games and is taking all of that context into the full algorithm."

First test corpus: the team's own all-hands transcripts + the May 5 post-game discussion (already recorded).

1. Agent-call capture (Phase 2, 1–2 weeks after Phase 1). Persist the (question, profile-context, response) tuple from MCP /sync calls that today is ephemeral. Already half-built — just needs a write.
2. In-channel capture (Phase 3, deferred). /sync log Telegram/Discord bot or in-product button. Only after Phases 1+2 validate signal quality.

Outcome tagging (ships with Phase 1). Every captured decision gets a 14-day follow-up nudge: "you decided X — worked / didn't / mixed + optional why." One click; optional free text. Without outcomes, trust-weight updates are speculative.

flowchart LR
    T[Transcripts<br/>Phase 1] --> X[LLM extraction]
    A[Agent calls<br/>Phase 2] --> X
    C[In-channel<br/>Phase 3] --> X
    X --> D[(decision_log)]
    D --> O[14-day outcome tag<br/>worked / didn't / mixed]
    O --> W[Trust-weight update]

Three capture layers feed one extraction pass into decision_log; only outcome-tagged decisions update trust weights.

Rationale

• Validates James's "mother algorithm" reframe with the smallest testable unit. Rather than committing to ZHC-scale closed-loop architecture, we ship the primitive and check whether real decisions produce trust-relevant signal. If they don't, the whole reframe needs revisiting.
• Piggybacks on artifacts users already produce. Decision-capture products fail when they require a new habit. Transcripts already exist; agent calls already happen. Both layers are zero-new-friction.
• Structurally parallel to multiplayer scenarios. A captured decision with N participants and individual stances is shaped like a multiplayer game session. That keeps the trust-weight update path consistent — same downstream consumers, same scoring math, just a different source.
• Outcome tagging is the actual differentiator. Most "decision logging" products track decisions and stop there. The 14-day outcome loop is what makes the data update trust weights instead of just sitting in a table.

Alternatives Considered

• Build the full ZHC closed-loop coordination layer (James's full vision). Rejected as Phase 1 because: (a) requires agent-to-agent infrastructure that doesn't exist yet, (b) commits to a much larger architectural surface before any signal-quality validation, (c) couples capture, attribution, and trust-update updates into one bet instead of three. The full vision remains the north star; this ADR is the foundation for getting there.
• In-product "log a decision" form (Layer 3 only). Rejected as Phase 1 because new-habit products with daily-friction asks die. Better to capture passively first.
• Skip outcome tagging; capture decisions only. Rejected. Decisions without outcomes generate noise the trust graph can't act on. Better to capture fewer decisions with outcomes than many without.
• Treat captured decisions as game scenarios — same table. Rejected. Game scenarios are designed instruments with controlled prompts and scoring rubrics; real decisions are messy and post-hoc. Conflating them muddies both data quality and game integrity. Separate table, parallel structure, downstream consumers can union if needed.

Discussion

Surfaced from the May 4 all-hands when James reframed Sync as the "mother algorithm" coordinating all org decisions, not just a profile builder from games. The user (CoachJ) initially read this as a much larger pivot than it needs to be — partly because James was describing the full ZHC closed-loop end-state. The deliberation that produced this ADR landed on: the primitive that closes the gap between "game-only" and "full coordination substrate" is non-game decision capture. That's the smallest testable unit.

Two design pressures pulled in opposite directions: - Bias toward capture breadth — the more decisions captured, the richer the graph. Argues for low-friction passive ingestion of everything. - Bias toward signal quality — game scenarios are calibrated; real decisions aren't. Capturing noise dilutes the trust signal Sync exists to produce.

Resolution: capture passively (transcripts, agent calls) but only count toward trust weights once outcomes are tagged. The 14-day outcome loop is the gate that filters captured-decision noise into actionable signal. Speculative until outcome-tagged, weighted thereafter.

Tash's coordination-substrate security concern (manipulation/capture risk if Sync becomes mastermind) is acknowledged but scoped to a separate ADR. This ADR is the data primitive; the access/manipulation surface that primitive creates is a related-but-separable design question that should not gate Phase 1 ingestion of the team's own meetings.

Open question deferred: how does a captured decision_log row update the existing judgment-layer signals? Phase 1 stores linked_signals_jsonb as extracted-but-not-yet-applied. The trust-weight integration (do real decisions weight equal to / less than / more than game scenarios?) is held until Phase 1 produces enough rows to evaluate empirically.

Consequences

• New decision_log and decision_participants tables required; migration to follow.
• Transcript-ingestion pipeline needs an LLM extraction prompt; cost is small (one extra Sonnet 4.6 call per meeting).
• Outcome-tagging UI needs a notification surface — could be email, in-product banner, or piggyback on existing dashboard. Smallest viable: dashboard banner that surfaces decisions awaiting outcomes.
• Pre-2026-05-05 decisions are not retroactively captured (would require manual ingest of historical transcripts; deferred).
• If Phase 1 data shows real decisions don't predict trust-relevant outcomes, this ADR is the trigger to revisit the full "mother algorithm" reframe rather than scaling to Phases 2–3.
• Watch: outcome-tag completion rate. If users don't tag outcomes, the captured data stays speculative and the whole loop fails. Target ≥ 40% tag rate at 14 days; below 20% means the nudge UX needs rework before more capture.

Key files (proposed): - migrations/0XX_decision_log.sql — schema for decision_log + decision_participants - src/lib/decisions/extract-from-transcript.ts — LLM extraction pipeline - src/lib/decisions/outcome-nudge.ts — 14-day follow-up logic - src/app/api/decisions/ingest-transcript/route.ts — Phase 1 entry point