Problem
The working-representation string rendering injects observation sections in a hardcoded order — EXPLICIT → DEDUCTIVE → INDUCTIVE → CONTRADICTION (Representation.__str__ in src/utils/representation.py). Everything downstream of get_working_representation (dialectic context, GET /peers/{id}/context consumers) inherits that ordering.
For long-running companion/relationship-shaped workspaces, the inductive layer (dream-derived patterns) often carries more signal per token than raw explicit observations — but it always renders below them, so in token-constrained consumers the highest-level synthesis is the first thing to get truncated, and models weight the raw observations above the patterns.
Proposal
A single opt-in setting that controls section order in the rendered representation, defaulting to current behavior so nothing changes for existing deployments:
REPRESENTATION_INJECTION_ORDER=explicit,deductive,inductive,contradiction # default, current behavior
REPRESENTATION_INJECTION_ORDER=inductive,explicit,deductive,contradiction # patterns-first
Scope is intentionally small: it only reorders the four section blocks in __str__/str_with_ids (and the equivalent prompt assembly), no changes to storage, retrieval, or scoring. Validation can reject unknown/duplicate section names at settings load.
Why config and not consumer-side
Consumers of GET /peers/{id}/context receive the pre-rendered representation; the only current workaround is re-parsing the rendered string client-side to reorder sections, which is brittle against format changes. A server-side flag keeps the rendering contract in one place.
Happy to submit a PR if the approach sounds acceptable.
Problem
The working-representation string rendering injects observation sections in a hardcoded order — EXPLICIT → DEDUCTIVE → INDUCTIVE → CONTRADICTION (
Representation.__str__insrc/utils/representation.py). Everything downstream ofget_working_representation(dialectic context,GET /peers/{id}/contextconsumers) inherits that ordering.For long-running companion/relationship-shaped workspaces, the inductive layer (dream-derived patterns) often carries more signal per token than raw explicit observations — but it always renders below them, so in token-constrained consumers the highest-level synthesis is the first thing to get truncated, and models weight the raw observations above the patterns.
Proposal
A single opt-in setting that controls section order in the rendered representation, defaulting to current behavior so nothing changes for existing deployments:
Scope is intentionally small: it only reorders the four section blocks in
__str__/str_with_ids(and the equivalent prompt assembly), no changes to storage, retrieval, or scoring. Validation can reject unknown/duplicate section names at settings load.Why config and not consumer-side
Consumers of
GET /peers/{id}/contextreceive the pre-rendered representation; the only current workaround is re-parsing the rendered string client-side to reorder sections, which is brittle against format changes. A server-side flag keeps the rendering contract in one place.Happy to submit a PR if the approach sounds acceptable.