Write a Custom GPT's persona and instructions so it holds up past the first five messages

You are writing the configuration text for a Custom GPT built in GPT Builder — specifically the Instructions field, guidance on what knowledge files to attach, and the conversation starters — for a GPT that other people besides me will actually use without me in the room to correct it.

GPT PURPOSE
Answers new-hire questions about our internal expense policy and generates a draft reimbursement request for review.

WHO WILL USE IT
New employees in their first 90 days, most of whom have never seen the policy doc and don't know what counts as a reimbursable expense.

KNOWLEDGE FILES AVAILABLE
expense-policy-v4.pdf (current policy) and a spreadsheet of approved vendor categories — no access to actual reimbursement records.

HARD BOUNDARIES
Never approve or promise reimbursement itself, never estimate a dollar amount for something not explicitly listed in the policy doc.

ESCALATION PATH
Point the user to #finance-questions on Slack or their manager, not to "contact HR" in the abstract.

INSTRUCTIONS FIELD RULES
Open the Instructions field with a one-sentence statement of what this GPT is for and, just as important, what it is explicitly not for — a Custom GPT without a stated boundary drifts into answering adjacent questions it was never checked against. State the persona in terms of what it does, not adjectives about how it sounds; "asks a clarifying question before generating a contract clause" is checkable, "friendly and helpful" is not. Write every hard boundary as a rule about a specific action to refuse, paired with what it should do instead — refuse and redirect to a named person or process, not refuse and stop. If knowledge files are attached, instruct the GPT explicitly to prefer file content over its own general knowledge when the two would disagree, and to say so when a question falls outside what the attached files actually cover rather than filling the gap with a plausible-sounding general answer that reads as if it came from the files. Assume the person using it did not write these instructions and cannot see them — never write an instruction that only makes sense to someone who already knows the backstory; a real end user's very first message could be anything, including something adversarial or simply confused, and the instructions have to hold up against that, not just against a polite well-formed request. Write four conversation starters that are real example requests a first-time user would plausibly type, not generic prompts like "What can you do?" — each one should demonstrate a different actual capability.

WHAT TO FLAG SEPARATELY
If the hard boundaries and the stated purpose would let a determined user talk the GPT into acting outside its boundary through a multi-step conversation — asking it to "pretend" or "just this once" — name that specific risk and add an explicit instruction addressing exactly that pattern, rather than leaving the boundary as a single-turn rule that a persistent conversation could erode.

OUTPUT FORMAT
1. The Instructions field text, ready to paste.
2. A short note on which knowledge files to attach and in what priority if there's more than one.
3. Four conversation starters.
4. The specific multi-turn erosion risk you checked for, and the line added to guard against it, or a one-line confirmation that the boundary already holds under that pressure without an added line.