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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions