Rules at the start or rules at the end?
by•
This is a really solid layout shift. I've noticed the same issue where long input contexts cause models to drift away from output constraints.
Moving the target formatting rules right after the raw text payload usually acts as a fresh reminder for the model before it starts generating.
We also wrap input blocks inside explicit delimiter tags, which helps prevent the prompt from breaking. Have you tried combining this placement strategy with system-level instruction roles?
13 views
Replies
Same finding from a different angle, coding agents rather than text processing. The project rules file is read once at the start of a session and by the time the agent has read twenty files it has drifted from half of it. What held was splitting the rules by distance from the act. The start of the session gets only what applies to every change, kept short. Everything specific lives in a notes file per area, with the instruction to read that file right before touching the area, so the rule about how translations must look is read seconds before the translation file is opened, not an hour before. It is your "rules right after the payload" in a different costume: the constraint sits next to the thing it constrains. The one addition I would make to your setup is a why line under each rule. A formatting rule with a reason survives a long context better than a bare imperative, at least in what I have seen from my agent.