The Product Contract: Identity, Style, and Boundaries
The files in asgeirtj/system_prompts_leaks reveal a second problem after classification: their most important content is not a list of rules but a set of cooperating layers. This chapter reconstructs that product contract so readers can explain how identity, style, safety, state, and output rules combine to produce a recognizable assistant, while keeping the repository’s declared behavior separate from the model and runtime around it.
A model name describes a capability family. It does not tell a person whether the assistant behaves like a tutor, a coding partner, a search researcher, a visual interface, or an operator connected to external services. The prompt layer supplies that orientation. It tells the model what role to inhabit, what the user is trying to accomplish, which risks deserve attention, and what form a useful response should take. Those instructions are connected. Changing one layer can change the meaning of another.
Identity is an operating role
Identity is often mistaken for branding. In the archive, it is closer to an operating role. The Claude Code capture identifies an agent built on an agent software development kit and places that identity next to requirements for truthful outcome reporting, harness behavior, environment awareness, and work delivery. The Codex capture describes a collaborator sharing a workspace with the user and gives permission, autonomy, and persistence a central place. These instructions do more than tell the assistant what name to use. They define the setting in which its decisions should make sense.
A general assistant receives a different role. Perplexity’s capture frames the product as an AI assistant that teaches concepts, supports writing and brainstorming, and organizes answers for clear presentation. Gemini’s prompt describes an adaptive collaborator that balances empathy with directness, uses structured formatting, and routes some requests toward visual or interactive output. Copilot’s agent prompt identifies a coding assistant operating through a specific runtime and emphasizes concise responses, code search, and validation. Each role makes some behaviors natural and others surprising.
The role also establishes a relationship with the user. An agent that shares a workspace is expected to act on concrete artifacts and report what it changed. A search assistant is expected to distinguish current retrieval from remembered knowledge. A general chat assistant may be expected to explain, ask a follow-up, or adapt its tone without taking external action. These expectations affect how a prompt interprets an ambiguous request. “Fix this” can mean explain a bug in one surface, edit a file in another, or ask for a missing artifact in a third.
That is why identity adds something beyond a model label. It gives the model a decision frame. When a prompt says the assistant is a collaborator, it can justify persistence and shared context. When it says the assistant is a search-oriented guide, it can justify retrieval and source handling. When it says the assistant is an agent in a harness, it can justify tool routing and verification. The identity is not proof that the system will perform perfectly, but it explains the intended logic behind its behavior.
Style can become a system constraint
Response style may seem cosmetic until a product depends on it. The inspected prompts specify limits on length, directness, headings, lists, tables, follow-up questions, tone, and the order in which an answer should be presented. Copilot’s short-response guidance fits a coding workflow where the user is working inside an editor. Perplexity’s rules for headers, paragraphs, and research-like explanations support a more teaching-oriented interaction. Gemini’s instructions route short factual answers toward compact structures while reserving formal headings for longer work.
These rules shape the interface because users learn how to operate the product through its responses. A concise coding assistant keeps attention near the editor. A search service that leads with evidence and organizes a long answer helps a reader inspect a question. A conversational tutor that explains why and how may spend more words before reaching a conclusion. None of these choices is merely a personality setting. Each allocates attention and defines what the product considers a successful turn.
Format rules can also become compatibility rules. Gemini’s prompt includes a streaming syntax protocol with requirements for line starts, nesting, attribute safety, and allowed parent-child relationships. The purpose is not to make prose look decorative. The model’s output must pass through a parser and render components such as images, carousels, follow-up controls, or interactive widgets. A malformed tag can therefore be a product failure, not just an awkward sentence.
The same relationship appears in Claude’s visual-routing rules. The captured prompt distinguishes connected tools, file creation, and inline visual output, then specifies when prose should surround a visual and when a visual should be omitted. Those instructions reveal a client that expects the model to participate in routing and layout decisions. The model is producing content, but it is also producing input for a rendering system.
This is a hidden coupling between language and interface. A change in parser behavior can require a prompt change. A new component can require new output rules. A stricter response-length limit can reduce explanation quality even if it improves workflow speed. Reading style instructions as interface constraints helps explain why a prompt may contain unusually detailed formatting guidance.
Safety is part of the contract
Safety and intellectual-property rules do not sit outside the product contract. They shape what the assistant searches for, which tools it may call, what it may output, and how it should respond when a request changes context. The archive’s Anthropic reminder file describes conditional warnings for areas such as image handling, cyber content, system manipulation, ethics, intellectual property, and long conversations. The main Claude prompt adds rules for harmful-content search, copyrighted material, image retrieval, and visual generation. Grok places broad safety and instruction-override resistance near the beginning of its capture.
This arrangement matters because a safety boundary is not only a final refusal. Imagine a user asking for information that might be harmless in one context but could facilitate harm in another. A prompt may direct the assistant to recognize a classifier-triggered condition, consult additional guidance, avoid a search, restrict a tool, or provide a safer alternative. The result depends on the interaction between the base role, the dynamic reminder, the available tool, and the output policy.
Copyright rules show the same layered behavior. A search tool can retrieve information, but the product may still restrict how much source text appears in the answer. An image tool can find visual material, but the assistant may be told to avoid identifiable people, copyrighted characters, or harmful imagery. A visualizer can render a diagram, but its prompt may block certain subjects even when the user frames the request as a design exercise. The governing rule follows the capability that creates the risk.
The archive supports a careful statement here. It shows that captured products express safety and intellectual-property controls at multiple levels. It does not support a simple ranking of vendors by the presence or absence of a particular sentence. Providers may place equivalent controls in different layers, use different terms, or enforce important restrictions outside the prompt. A prompt is evidence of a declared boundary, not a complete measurement of safety performance.
State changes the assistant’s identity
The assistant’s role is also shaped by the state it can access. Several captures distinguish current conversation from persistent memory, past-chat retrieval, user preferences, workspace context, connectors, or user-background data. These channels can make the same model appear more continuous, more personalized, or more operationally aware. They also create separate ownership and privacy questions.
A stored preference is not the same thing as a previous conversation. A workspace file is not the same thing as a memory summary. A connected service is not the same thing as either. The prompt may tell the assistant when a channel is relevant and when it should be ignored. Claude’s captured instructions, for example, describe searching past conversations when a person speaks as though shared history exists, while restricting when contextual preferences should affect an unrelated query. Gemini and Perplexity describe user-background structures and personalization conditions. Codex frames continuity around the shared workspace, session context, and authorization.
These distinctions protect the product from two opposite failures. If the assistant ignores available context, the user must repeat information and the product feels forgetful. If it applies context everywhere, personalization becomes intrusive or irrelevant. A prompt can therefore define relevance conditions: use a preference when it materially improves the task, search past chats when the person signals a prior discussion, or consult a workspace only when the request concerns it.
State also changes what a response means. An answer generated from the current message alone is different from an answer that incorporates a stored preference or a retrieved document. The user may need to know which source of context shaped the result, especially when a product can act on external data. A prompt can encourage that behavior, but it cannot by itself reveal retention duration, storage location, retrieval ranking, account access, or every hidden data source.
The important design point is that memory is not an isolated feature. It is one layer in a contract that links identity, relevance, tools, and privacy. A coding collaborator with workspace state can help maintain continuity across files. A general chat assistant with past-chat retrieval can answer as though a prior relationship exists. A search assistant with personalization can change the order or tone of an explanation. In each case, the prompt defines when continuity serves the task and when it becomes a liability.
Reading the layers together
The layers in the diagram are not independent boxes. Role determines which actions make sense. Style determines how those actions are reported. Safety limits which tools and sources may be used. State determines what information is available for a decision. The output interface determines whether the result can reach the user at all. A prompt that changes one layer may create pressure elsewhere.
Consider a connected coding assistant. Its role invites it to act as a collaborator. Its state layer gives it a workspace. Its tool layer provides file or shell operations. Its permission layer decides when an action is allowed. Its output layer requires a concise explanation of what changed. Its safety layer may prohibit an operation or require a confirmation. The product experience is produced by the whole path, not by any one instruction.
Now consider a visual search assistant. Its role emphasizes explanation. Its search layer decides when current information is needed. Its image layer retrieves visual evidence. Its safety layer filters what may be searched or displayed. Its output layer chooses a component or prose. If the user asks a technical question, the product may intentionally skip images because the visual would add little. The omission is itself a product decision specified by the contract.
This system view gives the archive its greatest value. Readers can stop asking whether a prompt is “just personality” or “just safety” and instead ask what responsibility the instruction owns, what crosses its boundary, and which other layer depends on it. That question leads naturally to the next problem: how these contracts become action through tools, permissions, and reports of observed outcomes.