Skip to content

Bug: Network exposures always use base event content, losing timeline/message provenance #116

@RandomOscillations

Description

@RandomOscillations

Summary

Network exposure records currently store content=scenario.event.content for every propagated exposure, even when the source is reacting to a later timeline epoch. This makes peer-transmitted information stale/incorrect and breaks message provenance in prompts.

Why This Is Major

The prompt renders network exposures as named statements, e.g. "X told me: <content>". If propagated content is always the initial seed event text:

  • Agents hear the wrong thing from peers
  • Later timeline developments do not propagate semantically through network paths
  • Exposure history appears repetitive and unnatural
  • Re-reasoning triggers may fire on new epochs while textual evidence still shows old content

This produces contradictory internal context and weakens scenario fidelity.

Current Behavior (Code Evidence)

In /extropy/simulation/propagation.py:

  • 467-472: network ExposureRecord is created with content=scenario.event.content
  • 473-489: info_epoch and force_rereason are propagated, but textual content is not tied to that epoch/source message

In /extropy/simulation/reasoning.py:

  • 135-142: prompt renders network exposure content verbatim as what peer said

So the model sees outdated/incorrect peer statements for timeline-driven updates.

Expected Behavior

Propagated network content should reflect what the sharer is actually transmitting, with epoch-consistent provenance.

At minimum:

  • If sharer's latest known epoch is k, propagated content should correspond to epoch k (or the sharer's own public statement grounded in k)
  • If no epoch context exists (static/non-timeline), fallback to base event content is acceptable

Proposed Fix

Option A (preferred): propagate sharer public statement

When creating network exposure:

  • use content = sharer_state.public_statement when available
  • fallback to epoch content (see Option B)
  • final fallback to scenario.event.content

Pros: most realistic peer-to-peer wording; aligns with "X told me"

Option B: propagate epoch-specific canonical content

  • Maintain map epoch -> timeline_event_content
  • For sharer with latest_info_epoch = k, set content from epoch k
  • fallback to base event content if missing

Pros: deterministic and compact; less variability than A

Additional safeguards

  • Keep info_epoch + force_rereason as-is
  • Ensure no empty content is written
  • Consider length cap/sanitization before persistence

Tests to Add

  • tests/test_propagation.py:
    • network exposure from timeline-aware sharer carries epoch-consistent content (not seed event text)
    • static scenario fallback still uses base event content
  • tests/test_reasoning_prompts.py:
    • rendered "X told me" lines reflect propagated content

Acceptance Criteria

  • In evolving scenarios, peer exposure text changes when new timeline epochs propagate
  • No systematic reuse of initial seed event text for all network exposures
  • Existing non-evolving scenarios remain stable

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions