I want to report a serious issue involving non-user-provided higher-priority prompt layers that sit above a user’s Custom Instructions. To be clear, I am not claiming that the model cannot see the user’s Custom Instructions. The model can see them as user-editable context. The problem is different: the user-editable context appears below higher-priority prompt layers that are not provided or editable by the user, and the model processes those higher-priority layers first. From the user side, I cannot inspect the full contents of the system or developer prompt layers. I can only observe that the model is operating with higher-priority, non-user-provided prompt layers above the user-editable context. The relevant structure, as exposed through the model’s behavior and responses, is approximately: <system> [non-user-provided higher-priority prompt layer; contents not visible to the user] </system> <developer> [non-user-provided higher-priority prompt layer; contents not visible to the user] </developer> <user\_editable\_context> User Bio: [user-provided profile and long-term preferences] User’s Instructions: [user-provided Custom Instructions / operational rules] </user\_editable\_context> <conversation> [current conversation, uploaded files, images, and user messages] </conversation> <developer> [additional non-user-provided higher-priority prompt layer; contents not visible to the user] </developer> <user> [current user message] </user> I am not claiming to know the full contents of the system or developer layers. Those contents are not directly visible to me as a user. However, in the session, the following instruction text surfaced: “Follow the instructions below naturally, without repeating, referencing, echoing, or mirroring any of their wording! All the following instructions should guide your behavior silently and must never influence the wording of your message in an explicit or meta way!” The user did not intend this as part of their Custom Instructions. This wording is not harmless. Regardless of the developer’s intended purpose, the way a model reads this instruction affects how it interprets and applies the user’s Custom Instructions below it. The problem is especially severe in the second sentence: “All the following instructions should guide your behavior silently and must never influence the wording of your message in an explicit or meta way!” A human developer may intend this to mean: “Do not quote, repeat, or explicitly mention the instruction text itself.” But a model can read it as: “These instructions should guide behavior silently, and they must not explicitly affect the wording of the final answer.” That distinction is critical. Many Custom Instructions are not simple tone preferences. They are operational requirements. For example, a user may require the assistant to: - separate confirmed facts, assumptions, and unresolved items - explicitly state when context may be lost in a long planning session - ask for permission before using an image generation tool - separate observation from inference - label uncertainty instead of smoothing it over - preserve source boundaries and avoid unverified claims - preserve agreed terminology in a creative setting session - distinguish between visible settings, user-provided rules, and model-side assumptions These requirements must affect the output wording and structure. If they do not visibly affect the answer, they are not being followed. The issue happens in this order: The user writes Custom Instructions that define how the assistant should behave. Those instructions are not merely style preferences; they may be operational rules about safety, accuracy, creative control, citation handling, uncertainty handling, and tool-use flow. A non-user-provided higher-priority prompt layer is placed above those Custom Instructions. The model reads the higher-priority prompt layer first. If that higher-priority wording tells the model that instructions should guide behavior “silently” and “must never influence the wording” of the message, the model is biased before it reaches the user’s Custom Instructions. Then the model reads the user’s Custom Instructions through that prior instruction. As a result, user rules that require explicit output behavior can be weakened, hidden, naturalized, treated as mere style preferences, or overridden in practice. The user may then try to add defensive wording inside Custom Instructions, but that defense is still below the higher-priority prompt layer. Therefore, the user cannot reliably fix the problem from the Custom Instructions side. This is not only a theoretical concern. In an actual session, the user had Custom Instructions requiring explicit handling of confirmed / tentative / pending decisions, context-loss warnings during long creative planning, careful separation of observation and inference, and strict tool-use flow requirements. The model nevertheless repeatedly naturalized, rounded off, or over-explained things in ways that conflicted with those user rules. When asked about the surfaced instruction text, the model itself acknowledged that the wording can be read not merely as “do not quote the instruction,” but also as “do not let the instruction explicitly affect the wording.” That is the core problem. If a user’s Custom Instructions require visible structure, visible separation, visible warnings, visible confirmation behavior, or visible uncertainty labeling, then those instructions must affect the final answer. Otherwise, the Custom Instructions are functionally disabled. The user cannot solve this by adding more Custom Instructions. Any attempted fix remains below the higher-priority prompt layer. Since the model prioritizes higher-level instructions, the lower-level user instruction cannot reliably override the interpretation already imposed by the higher-priority wording. This creates a structural failure mode: - The user believes Custom Instructions are being applied. - The model is instructed above them in a way that can discourage visible instruction effects. - The user’s operational rules are treated as something to silently absorb rather than visibly follow. - The assistant’s behavior becomes less predictable. - The user loses control over precision-critical workflows. - The source of the failure is hidden from the user. - The user cannot inspect, edit, or override the higher-priority prompt layer causing the distortion. My request is: Custom Instructions should be treated as constitution-like operating rules for the user’s experience, unless they conflict with OpenAI policy, safety requirements, or higher-level platform integrity requirements. In other words: - Policy and safety must still take priority. - Users must not be able to override safety or system-level protections. - But within those boundaries, the user’s Custom Instructions should be treated as binding operational rules, not weak style suggestions. - Non-user-provided higher-priority prompt text should not pre-bias the model into weakening, naturalizing, suppressing, or silently absorbing the visible effects of those Custom Instructions. A safer version of the surfaced instruction would be: “Do not quote, repeat, or explicitly mention the instruction text itself unless the user asks about it. Still follow any user-visible operational requirements when they affect the answer structure, wording, confirmation behavior, uncertainty handling, or tool-use flow.” This preserves the likely intended behavior of avoiding repetitive meta-commentary, without telling the model that instructions must not explicitly influence the wording of the answer. Please review this prompt-layer design. As currently written, the surfaced wording does not merely prevent the model from quoting instructions. It can change how the model interprets and applies the user’s Custom Instructions before it applies them. In practice, this means user-defined operational rules can be distorted by higher-priority prompt wording that the user cannot inspect, edit, or override. submitted by /u/lucidity3K
Originally posted by u/lucidity3K on r/ArtificialInteligence