Skip to content

ADR-016: Delegation as a First-Class Game Action

Status: Accepted Date: 2026-03-29 Context: During the March 23 multiplayer session, CoachJ had low conviction on the Innovation Team Revolt scenario. After the reveal phase, Amin shared his rationale — a compelling analysis grounded in the Google/ChatGPT precedent about how companies must restructure to compete in the AI era. CoachJ's reaction was immediate: "Sold. I'm sold. That is some amazing rationale." He then articulated what he wished the game would let him do: "My vote is to delegate my vote away to Amin and let him make the decision." This is not a hypothetical — it's the exact mechanism that Cesar Hidalgo describes in the direct-democracy-with-software-agents model, and it's the same delegation pattern CoachJ previously implemented in a cap table agent product. The game currently lacks a way to capture this signal.

At a glance

What it decides: After the multiplayer reveal-and-discussion phase, players choose one of three post-discussion actions — Stand, Revise, or Delegate — turning the informal "I'd give my vote to Amin" instinct into structured trust data. (ADR-021 later partially simplified this three-action model; this ADR documents the original design.)

  • Three actions, three signals — Stand confirms a choice under challenge (weight ×1.3), Revise captures what changes the player's mind (original ×0.3, new ×1.0), Delegate records a contextual trust edge to a specific peer (and does not pollute the driver distribution).
  • Delegation is directional trust, not abstention — "I trust this person's judgment in this context," the Cesar Hidalgo augmented-democracy mechanism the DTA needs for autonomous routing.
  • Alternatives rejected — binary revise-or-keep (misses delegation), pre-scenario delegation (lacks context), and inferring delegation from prediction accuracy (predictability ≠ trust).
  • Consequence — multiplayer sessions become far more valuable for DTA training than solo, and ADR-011's delegation map gains a human-to-human layer.
flowchart TD
    R["Reveal + discussion<br/>(peer rationales shared)"] --> Q{"Post-discussion<br/>action"}
    Q -->|Stand| S["Keep original answer<br/>weight ×1.3 (survived challenge)"]
    Q -->|Revise| V["New option + rationale<br/>original ×0.3, revised ×1.0"]
    Q -->|Delegate| D["Give vote to a peer<br/>record trust edge; no driver update"]

The three mutually exclusive post-discussion actions and what each contributes to the profile.

Decision

After the multiplayer reveal and discussion phase, players should be offered three distinct post-discussion actions:

1. Stand — "I'm keeping my answer"

The player heard others' rationales and remains convinced of their original choice. This is a confirmation signal — it strengthens the profile weight for this choice because it survived deliberative challenge.

2. Revise — "I'm changing my answer, and here's why"

The player was persuaded by someone else's reasoning or by the discussion itself. The player selects a new option and provides a brief rationale for the change. Both the original choice (at reduced weight) and the revised choice (at full weight) feed the profile. The rationale is particularly valuable — it captures what kind of argument changes this player's mind.

3. Delegate — "I'm giving my vote to [player] for this decision"

The player selects a specific peer to delegate their decision to. This means: "I trust this person's judgment in this context more than my own." The player optionally explains why. The delegated-to player's choice becomes the delegator's effective choice for this round.

Rationale

Delegation is not abstention — it's directional trust

Abstaining says "I don't care" or "I refuse to engage." Delegating says "I recognize I'm out of my depth, and I actively choose to trust [specific person] in this context." This is an extremely high-signal action for the DTA because it captures: - Situational epistemic humility — the player knows the boundary of their competence - Directional trust — not "I trust Amin generally" but "I trust Amin on competitive market strategy questions" - Voluntary authority transfer — the exact mechanism the DTA needs for autonomous governance

This is the Cesar Hidalgo model in miniature

Hidalgo's augmented democracy proposal combines direct participation with software agents: citizens can vote directly on issues they care about and understand, or delegate specific policy domains to trusted agents (human or AI). The Sync game becomes the training ground for this model. By capturing delegation patterns — who delegates to whom, in what contexts, after what kind of discussion — the DTA learns a delegation graph that it can eventually execute autonomously.

The game already surfaces the delegation instinct

CoachJ's reaction to Amin's rationale was a natural delegation impulse. The game currently forces this into an informal verbal expression ("I would have delegated to you") that isn't captured by the system. Making delegation a structured game action turns an existing behavior into structured data.

All three actions are high-signal for different reasons

Action What the DTA learns
Stand "My operator is confident in this context — this pattern is load-bearing"
Revise "My operator can be persuaded by [type of argument] — and values [revised driver] over [original driver] when challenged"
Delegate "My operator defers to [person] in [context] — route similar decisions to their DTA"

Prior art: the cap table agent

CoachJ previously built a cap table management agent where token holders could delegate voting authority to other holders for specific proposal categories. The pattern is identical: "I believe they are better able to analyze the situation and determine what's going to be best." The difference in Sync is that delegation is learned from game behavior rather than manually configured.

Alternatives Considered

  • Only offer "Would you like to change your answer?": Binary revise-or-keep. Rejected because: this misses the delegation signal entirely. Changing your answer to match Amin's is different from delegating to Amin. In the first case, you're claiming the decision as your own. In the second, you're routing authority — a fundamentally different governance action.

  • Add delegation as a standalone game mechanic separate from the post-discussion phase: Create a "delegation round" where players can preemptively delegate before seeing the scenario. Rejected because: meaningful delegation requires context. You delegate after discovering that a specific scenario is outside your competence and that a specific peer has demonstrated expertise. Pre-scenario delegation would be a general trust measure (which the trust round already captures), not a contextual one.

  • Make delegation implicit from prediction accuracy: If Amin consistently predicts my choices correctly, infer that I should delegate to him. Rejected because: predictability ≠ delegation. Someone can predict me without being someone I'd trust to decide for me. Delegation is about judgment quality, not prediction accuracy.

  • Allow delegation to the DTA itself: "I trust my AI more than I trust myself here." Interesting but premature. The DTA's judgment quality hasn't been validated enough for this to be meaningful. Deferred to a future phase when DTA confidence in specific contexts is established.

Discussion

The core insight from the March 23 all-hands was that the multiplayer post-reveal discussion phase is where the most valuable trust signals emerge. James described it as analogous to agile retrospectives: "the retrospectives are almost as important because the retrospectives are what you build on." The reveal shows what people chose; the discussion reveals why; and the post-discussion action captures what changed.

The team debated whether the three-action model (Stand/Revise/Delegate) adds too much complexity to the game flow. The counter-argument: the actions are mutually exclusive and take seconds to execute — tap Stand, or tap Revise and pick a new option, or tap Delegate and pick a person. The value per interaction is extremely high.

A deeper philosophical tension emerged: is delegation a sign of weakness or strength? In traditional governance, abstaining or delegating is often seen as disengagement. But in the Hidalgo model — and in the Beacon vision — delegation is a competence signal. It means you know what you don't know, and you know who does know. The DTA that learns this pattern becomes more trustworthy than one that pretends confidence in every domain.

Connection to ADR-015 (Decision Conviction): Low conviction is the natural precursor to delegation. The typical flow is: encounter scenario → low conviction → choose performatively → hear peer rationale → delegate. The system should capture this full chain as a coherent behavioral pattern, not three disconnected data points.

Connection to ADR-011 (Delegation Map): The delegation map currently describes what the DTA is confident enough to auto-decide. This ADR adds the human-to-human delegation layer: when the DTA encounters a context where it lacks confidence AND the player has a historical delegation pattern to a specific peer in that context, it can route the decision to that peer's DTA rather than flagging for human review. This is graduated sovereignty with a social dimension.

Implementation Notes

Data Model

-- New table or extend existing choices table
create table post_discussion_actions (
  id uuid primary key default gen_random_uuid(),
  session_id uuid references game_sessions(id),
  scenario_id uuid references scenarios(id),
  user_id uuid references profiles(id),
  action_type text check (action_type in ('stand', 'revise', 'delegate')),
  -- For revise: which option they changed to
  revised_option_id text,
  revised_rationale text,
  -- For delegate: who they delegated to
  delegated_to_user_id uuid references profiles(id),
  delegation_rationale text,
  -- Context for the DTA
  original_decision_strength int,
  created_at timestamptz default now()
);

Game Flow

  1. All players make choices (existing)
  2. Peer predictions (existing)
  3. Trust ratings (existing)
  4. Reveal + AI predictions shown (existing)
  5. Discussion phase — players share rationales (currently informal; could be structured with text input)
  6. NEW: Post-discussion action — Stand / Revise / Delegate
  7. Final results with any revisions/delegations reflected

Profile Integration

  • Stand: Boost the original choice's weight by 1.3× (survived challenge)
  • Revise: Original choice at 0.3× weight, revised choice at 1.0× weight; extract "what changed their mind" from rationale
  • Delegate: Record delegation edge with context (scenario category, triggers, decision_strength); do NOT update driver distribution from the delegated choice (it's not their decision)

Consequences

  • The multiplayer game flow gains a new phase after reveal
  • A new data model captures Stand/Revise/Delegate actions with context
  • Trust edges become richer: the existing trust round captures general trust; delegation captures contextual, demonstrated trust
  • The DTA's delegation map (ADR-011) gains human-to-human delegation patterns as training data
  • Profile updates become more nuanced: confirmed choices count more, uncertain choices count less, delegated choices don't pollute driver distributions
  • The game becomes a more complete model of the Hidalgo augmented democracy vision
  • Multiplayer sessions become significantly more valuable for DTA training than solo sessions (solo captures decisions; multiplayer captures decisions + social trust dynamics)

Key files: - src/app/play/[sessionId]/page.tsx — New post-discussion phase UI - src/app/api/sessions/complete/route.ts — Handle Stand/Revise/Delegate in scoring - src/lib/ai/player-model.ts — Profile update logic for each action type - src/types/database.ts — New PostDiscussionAction type - Migration file — New post_discussion_actions table