> For the complete documentation index, see [llms.txt](https://docs.allshore.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.allshore.ai/clients-and-pipeline/the-candidate-record.md). # The candidate record Everything about one person in your pipeline: their profile, what the client has been told, their documents, their offers, and their history. ## Profile and notes The **typed profile** holds the structured facts you work from — the sort of thing you'd otherwise keep in a spreadsheet. Notes are free text for everything else. Editing the profile only records a change when something actually changed: re-saving an untouched form, or clearing a field that was already empty, writes nothing at all. That keeps the record's history answering "when did this really change?" rather than "when did somebody open the form". The history notes **which fields** changed, never their values — a person's details don't get copied into a trail that's read far more widely than the record itself. ## Submitting to the client Submitting a candidate attaches a **summary you write**, and that act is what makes them visible to the client at all. Until you submit, a candidate is invisible in the portal — you can source, assess, and discard people without the client ever knowing they were considered. Once submitted, they stay visible through the later stages, and the summary is the only substantive thing the portal shows about them. Names, contact details, profile fields, notes, and documents never reach the client. That makes the summary a real editorial act: it's your pitch, curated deliberately, rather than a dump of whatever's on file. It's also why moving a candidate's stage by hand isn't the same as submitting them — a candidate who never got a summary was never put forward, and the client's screen reflects that. ## Documents The document ledger holds the candidate's paperwork, each filed by kind: * **Resume** — the candidate's own document. * **CV write-up** — your firm's rewrite of it. Deliberately a different kind, not a version of the resume: different author, different audience. * **Portfolio** — work samples. * **Other** — the honest catch-all, so nothing gets mis-filed to make it fit. * **Offer letter** — generated rather than uploaded. Rendering an offer letter files it here automatically, which is why it appears among the documents but isn't a choice in the upload picker. ## Offers An **offer** is a real record with a terms snapshot, not a note that you made one. Its life: * **draft** — being prepared. * **extended** — put to the candidate. * **accepted** / **declined** — what the candidate said. Those are the only two responses you can record; the other endings aren't the candidate's to choose. * **withdrawn** — you pulled it. * **expired** — its response deadline passed and the expiry was recorded. A response deadline is **optional**. Set one and the offer can be expired once it passes; leave it off and the offer stays extended until somebody answers, withdraws it, or it's hired against. Nothing times out on its own — an offer with no deadline can sit open indefinitely, so set one if you want the pressure. You can render the **offer letter** from the record and send it, with the send tracked the same way document and proposal sends are — see [Sending & countersigning](/clients-and-pipeline/sending-and-countersigning.md) for how to read outcomes. Through the conversational connector, sending an offer letter is confirmation-gated. An accepted offer is what unlocks hiring, and it can only be spent once. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.allshore.ai/clients-and-pipeline/the-candidate-record.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.