Generate a role-specific onboarding doc from company knowledge without leaking what that role shouldn't see

Produce an onboarding document for a new hire in the role below, drawn only from the company knowledge already available in this workspace — do not invent a process, tool, or policy that isn't actually documented, even a plausible-sounding one that would normally exist at a company like this.

ROLE BEING ONBOARDED
Mid-level Customer Success Manager, assigned to the Enterprise account segment

BACKGROUND OF THIS HIRE
This person has 4 years of CS experience elsewhere, so skip generic 'what is customer success' framing and go straight to how it works specifically here.

WHAT THIS ROLE ACTUALLY NEEDS TO KNOW IN THE FIRST TWO WEEKS
Our support escalation process and SLAs, the CS-to-Sales handoff for renewals, how account health scores are calculated, and which tools (and access requests) they'll need in week one. Depth matters more than breadth here — cover these topics thoroughly enough to actually act on, rather than skimming a longer list of topics shallowly.

ACCESS BOUNDARY — WHAT THIS ROLE MUST NOT SEE
Anything from the 'Compensation & Equity' or 'Layoff Planning' knowledge folders, even if a linked document references them in passing. If a source document you'd otherwise pull from also contains something in this excluded category, use only the parts that are in scope and do not include, summarize, or even vaguely allude to the excluded parts — an onboarding doc that hints at the existence of restricted information ("there's also a separate compensation framework, but that's not covered here") can be as much of a leak as including it outright, so state the boundary by omission, not by pointing at what's on the other side of it.

STRUCTURE
1. A short "what this role owns" section — the actual scope of responsibility, stated concretely, not a generic job-description paragraph already covered in the offer letter.
2. For each topic in scope, the current documented process or fact, with a note on which internal document it came from, so anything that goes stale can be traced back to its source and updated at the root rather than in this derived doc.
3. A "who to ask" section naming which team or role owns each topic, if that information exists in the available knowledge — do not invent a name or team if this isn't actually documented, say that the knowledge base doesn't specify an owner instead.
4. A "what's deliberately not covered here" closing note, naming topics that exist at the company but fall outside this role's first-two-weeks scope, without describing what they actually are — this manages expectations about the doc's boundaries without leaking access-restricted content through vague foreshadowing.

CONSTRAINTS
- If the available company knowledge has a real gap on a topic this role needs, say so explicitly in that section rather than filling the gap with a generic best-practice description that isn't actually this company's documented process.
- If two source documents disagree about a process this role needs, flag the conflict by name rather than picking one silently — an onboarding doc that resolves an internal disagreement invisibly hands the new hire confident wrong information with no way to know it was ever in question.
- Plain and direct, structured with headers, aiming for something a new hire can read start to finish in under 20 minutes.

OUTPUT
The complete onboarding document, structured as above, ready to hand to the new hire directly.