ADR-014: Relational Proximity as Decision Modifier¶

Status: Accepted Date: 2026-03-29 Context: During a solo game, CoachJ encountered a scenario about offshoring a small agency's development team after losing a major client (40% of revenue). His historical pattern favored efficiency/revenue optimization for anonymous workforces at larger companies. But in this scenario, the characters had names, backstories, and recent life events — "James just bought a house, Rebecca just had a kid." CoachJ chose a people-first option the AI did not predict, specifically because he knew the people affected. This revealed that relational proximity to the humans impacted by a decision is a major modifier of decision-making behavior that the profile system does not currently track.

At a glance

What it decides: Relational proximity — whether the decision-maker personally knows the people affected — is tracked as a context trigger and modeled in the profile, so the system can capture that a player decides differently for named individuals than for an anonymous workforce.

A relational, not situational, modifier — distinct from triggers like crisis or resource constraint; same stakes, but "the engineering department" vs. "Tomoko, who relocated from Osaka" produce different behavior.
Divergence is signal, not noise — when a high-proximity choice breaks the player's low-proximity pattern in the same category, that is recorded as a real, predictable axis (not smoothed away by EMA).
Alternatives rejected — treating it as variance, tagging scenarios without profile-level tracking, and standardizing all scenarios to one proximity level (which would erase the diagnostic contrast).
Consequence — profiles get richer ("efficiency-first with anonymous teams, people-first when personally connected") and lay groundwork for the DTA to use real social-graph trust edges in governance.

Decision¶

Relational proximity — whether the decision-maker has personal knowledge of and relationships with the people affected — should be recognized as a context dimension that modifies decision-making behavior. The system should:

Track it as a context trigger: Add relational_proximity (or known_individuals) to the trigger taxonomy alongside existing triggers like crisis_mentioned, team_conflict, resource_constraint, etc.
Detect it in scenarios: Scenarios that name specific people with backstories, tenure, and personal details create relational proximity. Scenarios about anonymous workforces or abstract headcounts do not.
Record divergence: When a player's choice in a high-proximity scenario diverges from their pattern in low-proximity scenarios of the same category, this is signal — not noise. The profile should capture that this player behaves differently when they know the people.
Surface it in the DTA profile: The learning notes and profile analysis should be able to say something like: "In resource decisions affecting anonymous teams, CoachJ optimizes for efficiency. When specific individuals are named with personal context, he shifts to people-first decisions."

Rationale¶

The "spreadsheet vs. story" distinction is real and consequential¶

As James noted in the all-hands discussion, there's "a whole case against organizations that just look at spreadsheets and people as numbers versus what is the story behind this group of people." This is not a flaw in decision-making — it's a feature of human judgment. People who shift their decisions based on personal knowledge of those affected are exhibiting a form of contextual wisdom that governance systems should model, not flatten.

This is distinct from existing context triggers¶

The current trigger taxonomy captures situational modifiers — is there a crisis? a resource constraint? an ethical dilemma? But relational proximity is a relational modifier — it's about the decision-maker's connection to the people in the scenario, not the type of situation. A resource allocation decision can have identical stakes but produce different outcomes depending on whether the affected team is abstract ("the engineering department") or personal ("Tomoko, who relocated from Osaka for this role").

The AI mispredicted because it lacked this dimension¶

The prediction model had strong signal that CoachJ favors efficiency in resource allocation scenarios. That signal was correct for anonymous/large-org contexts. The misprediction occurred because the model couldn't distinguish between "resource allocation with abstract workforce" and "resource allocation with known individuals." Adding relational proximity as a tracked dimension would allow the rule engine to build separate behavior distributions for each case.

Governance implications¶

In a DAO, some governance decisions affect strangers (token holders you've never met) and some affect people you've worked with directly. If a delegate's DTA doesn't model the relational proximity effect, it will apply the "anonymous workforce" pattern universally — which may be exactly wrong for decisions affecting close collaborators.

Alternatives Considered¶

Treat it as noise and let EMA smooth it out: The misprediction is just variance; over enough games the pattern will average out. Rejected because: the relational proximity effect is systematic, not random. CoachJ will consistently shift toward people-first decisions when he knows the individuals. Smoothing this away loses a real and predictable behavioral pattern.
Add it as a scenario metadata tag but don't track it in profiles: Flag scenarios as "high proximity" or "low proximity" during generation, but don't build it into the prediction model. Partially adopted — tagging scenarios is useful for analysis, but without profile-level tracking, the prediction model can't use it.
Make all scenarios either high-proximity or low-proximity for consistency: Standardize scenario generation to always (or never) include named characters with personal details. Rejected because: the variation IS the diagnostic signal. The game needs both types to detect whether a player's behavior shifts.

Discussion¶

This insight emerged from the March 23 all-hands when CoachJ described the offshore scenario. The team discussion surfaced a broader theme: decision-making is not context-free; it is relationship-dependent. James framed it as "people as spreadsheets vs. people with stories." 08 connected it to why DAOs fail — they optimize for trustless coordination and ignore relational dynamics.

The key tension debated was whether this represents a limitation of the current system (it should model relational proximity but doesn't) or a feature (the DTA should apply consistent principles regardless of personal connections). The resolution was that both behaviors — the abstract-efficiency pattern AND the relational-proximity pattern — are authentic expressions of the player's values. The DTA should know about both and understand when each applies.

A secondary question arose: in actual DAO governance, should the DTA apply the "I know these people" pattern or the "anonymous workforce" pattern? The answer likely depends on whether the DTA actually has relational data about the affected parties — which connects to the trust edges and multiplayer profile data being collected now.

Consequences¶

The context trigger taxonomy expands to include relational modifiers, not just situational ones
Scenario generation may need to deliberately vary proximity level within the same category to build discriminating signal
The prediction model gains a new axis for behavior distribution — same category, same triggers, but different proximity = potentially different predictions
Profile summaries become richer: "efficiency-first with anonymous teams, people-first when personally connected"
This creates a foundation for the DTA to eventually use its actual social graph data (trust edges from multiplayer) to modulate its governance decisions based on who is affected

Key files: - src/lib/ai/player-model.ts — TRIGGER_KEYWORDS needs relational_proximity added - src/lib/ai/learning-notes.ts — Learning note extraction should flag proximity-driven divergence - src/lib/ai/scenario-generator.ts — Scenario generation should deliberately vary proximity levels - src/app/api/ai/classify-driver/route.ts — Semantic classifier should detect relational proximity triggers