# Fundraising actions

## Round names

When proposing or creating a round name, use the round type and year, such as `Seed Round 2026`. Omit the company name because Ray already shows the company in the surrounding interface, and repeating it makes round labels redundant throughout the site. Preserve any additional qualifier needed to distinguish rounds. A request to note this convention does not itself rename existing records.

For an explicit rename request, retrieve the existing rounds with `list_rounds`, including previous rounds, and follow pagination. Use `rename_round` with each round's refcode and verify the result. Preserve stage, year, and distinguishing qualifiers; resolve any resulting name collision. Do not create replacement rounds to change their labels. If the connected server lacks these tools, report the missing capability instead of claiming the names were changed.

## What the company is

What the company is belongs in the company's story, and `save_company_story` is the one place to send it. The story is prose in the company's own words under named topics (what we do, the problem, what people do today, the product, who it is for, what we know that others don't, why now, traction, how we reach customers, how we make money, the market, the team, why we stay ahead, risks and what is proved, where it goes), short facts (location, founded, website, product link, category), and any topic of the company's own under `other_topics`. There is one story for the company; what is being raised is on each round. Do not keep any of this in a note.

Send only the topics the user stated or changed. A topic left out, or sent as null, keeps its value; to remove one, name it in `clear`. Figures (customers, revenue, conversion, market size) go in only when the user gives them. Every member of the company and every agent acting for one can read the story, and agents draft messages to investors from it, so everything in it must be something that may be said to an investor; tell the user what you left out and why. Changing it needs `manage_rounds`.

When the user wants to work on the story, or `get_fundraising_context` says topics are missing and there is room in the conversation to offer, coach them through it one topic at a time: [The company's story](company-story.md) has the questions, what a strong answer contains and the follow-ups for a vague one.

When drafting to an investor, take what the company does, the problem, the product, traction and the team from the story. `get_fundraising_context`, `get_meeting_brief` and `get_email_context` all return it as `company_story`, with `not_written` naming the named topics the company has not written. Ask the user before writing about one of those, and offer to save the answer.

## The round's goal and plan

What the raise is belongs on the round, and `update_round` is the one place to send it: the target, minimum and cap, the target close, the status, and the plan. The plan holds the approach (the instrument and how the round is being raised), the smallest and largest check, a short description of the investors the round is for, a narrative, and markers. Do not keep any of this in a note. A note about the plan that an import left behind is source material; the round's plan is the record.

Send only what the user stated or changed. A part that is left out, or sent as null, keeps its value. To remove a part, name it in `clear`. The narrative and the markers are each replaced whole: read the round first (`get_round_operating_view` returns `round.plan`), revise the text or the list, and send all of it, including the markers to keep. Name the round by its refcode or its exact name.

Only a date the user states as the goal becomes the target close. Timing they are unsure of ("first close in early November, something like that") is a marker, in their words: a label with a date, or with a first and a last day when it covers a period. A loose time such as "early November" is a period that covers it. Markers appear on the round's time bar and the Calendar, and nothing is counted against them, so do not treat one as a deadline or create a task for it unless the user asks.

The narrative is prose under any headings: why this amount now, what the money pays for, what it gets the company to, and the raise after this one. Hiring, offices and company targets are sentences in it; there are no fields for them. Every member of the company and every agent acting for one can read it, and agents draft messages to investors from it, so everything in it must be something that may be said to an investor. Leave out what should not reach one, such as cash on hand or a fallback the founders would not announce, and tell the user what you left out and why. If you cannot tell whether something may be said, ask before saving it.

When drafting to an investor, take the amount, the use of the money and the milestones from the narrative, and what the company is from the company's story. `get_email_context` and `get_meeting_brief` return the narrative under `rounds` for the rounds that investor's deals belong to, and the story under `company_story`; `get_fundraising_context` returns both for every running round. Add no figure the narrative or the story does not contain: not a valuation, a traction number or a date. If the draft needs one, say it is missing. [Messages to investors](messages.md) has the whole procedure for a draft.

Status changes go through the same operation. Starting a planning round records today as its opening date. Until then it has not opened: its `opened_on`, `days_open` and `days_planned` are empty, so do not describe a round in planning as open or count its days. Closing or abandoning records the closing date, today unless the user gave an earlier one. Reopening clears it. Amounts are the plan, never money received, and changing a round changes no investor's record. Changing a round needs `manage_rounds`, normally held by owners and admins; report a refusal instead of writing the plan into a note.

## Record the event once

When the user describes an actual investor exchange, use `record_event`. It resolves the firm and people and records the activity, stated follow-ups, revisit date, and intelligence in one operation. Search first only when needed for a separate question; the recording tool handles ordinary name resolution itself.

An exchange you found yourself in the user's mail, calendar or documents, which the user did not tell you about, goes through the same tool with `found_in` naming the message, event or document. It then follows the user's calendar and inbox rule: normally a private proposal for them to approve, and nothing at all when a capture exclusion covers it. [Messages to investors](messages.md) describes catching up this way before a draft.

Include stage, expected amount, commitment, or waiting-on in that same call only when the user stated them. Enthusiasm does not imply a commitment. A meeting does not imply diligence. A secondhand report belongs to intelligence with `secondhand_report`, not an inferred pass or stage change. Small talk, speculation, marketing mail, and internal teammate conversations are not investor events.

An expected amount is the user's own estimate of what one investor may put in ("I think Acme is good for $250K"). Record it when the user states one: with the event in the same call, or on its own with `update_deal`. It is not a commitment and not money received, so call it expected when you report it, do not change the stage because of it, and never work one out from a firm's usual cheque size or from what another investor is putting in. What the investor themselves said they will do is a commitment, recorded as the next section says, and it leaves the estimate as it is. When the user withdraws an estimate, or it was recorded on the wrong investor, remove it with `clear: ["expected_amount"]` on `update_deal`; do not set it to zero. `get_round_operating_view` returns each investor's `expected_amount` and `currency`, and the round's `active_expected` and `committed_expected` add up those in the round's currency. Amounts in another currency are never added in, and `other_currency_expected` says how many were left out; report them separately and do not convert them. The round page sets those totals against the target and says how many investors the target takes at the plan's check sizes.

If resolution fails, use the returned question. Only record a separate event when the user establishes that it was separate; the next section says what to do when the event is already recorded.

An event from an earlier day always carries its date. Ray reads an event sent without one as "just now" and dates it at the moment of the call, whatever date the summary names; the result says so ("dated … now: no date was given"), and if you see that on a past event, correct it with `revise_event`. When the user gave a time, send `occurred_at`. When they gave the day and no time ("we had lunch Thursday"), send `occurred_on` with that day and do not ask for the hour. The result says it back as the day only, and every later read of the event says `day_only: true` (a deal's last event, `last_event_day_only`): its `occurred_at` is noon that day, a time nobody gave, so give the user the day and no time. Leave both empty only for something happening now or within the last few hours.

## One event, one record

One real event is one record, however many people describe it and however many times. A teammate, an earlier session or a catch-up may already have recorded what the user is telling you. Ray checks when you record, and answers in one of three ways.

It recognises the event. The same investor has a compatible event within twelve hours of the time you sent (a day sent as `occurred_on` covers that whole day; meetings, calls and events are compatible with each other, and so are emails and messages). Nothing is duplicated. A follow-up, intelligence or a commitment the user stated is still recorded, and the first time a given person describes the event their account is attached to it as evidence. The result's `existing` holds the record as it stands: its summary, detail, date, who recorded it, everyone whose account it carries, and its `version`.

It asks. For a meeting, call or event the user dates before today, Ray also looks three days either side, because two accounts of one lunch often differ by a day. If it finds one, nothing is written and the result is a question listing the recorded events and who recorded each. Put the question to the user. If it is one of them, call again with that refcode as `existing_event`. If the user says it was a different event, call again with `separate_event` set. When the user's own account already names both events ("we spoke Monday and again Thursday"), they have said it, and you can set `separate_event` without asking. Never change the date to get past the question.

It records a new event, because nothing recorded is near it.

When Ray hands you `existing`, compare it with what the user just said, every time. `already_recorded` is where that comparison starts. If their account adds something the record does not hold, or corrects it, rewrite the record with `revise_event`: the record's refcode, its `version` as `based_on`, and the whole new `summary` or `detail`. The summary stays one or two sentences that cover what is now known, and the added colour goes in `detail`. Keep every fact the record already holds unless the user corrected it; you are adding to a teammate's account, not replacing it. Do not put the addition in a note and do not record the event again to hold it. If their account adds nothing, say it was already recorded and leave it.

If the two accounts disagree on a fact (the day, who was there, what was offered), do not pick one. Say what is recorded and by whom, ask the user, and then correct the record with `revise_event`, where `occurred_at` or `occurred_on` changes the date.

A revision is refused when someone changed the record after the `version` you hold. Read the record again (`recent_events` in `get_meeting_brief` gives each event's `version`), compare, and send the revision again based on what is there now. The earlier wording of every revision stays in the audit trail, and the person revising is added to the event's sources.

If you find the same event recorded twice, tell the user. `get_meeting_brief` warns of two meetings, calls or events with an investor in common within three days of each other, naming both refcodes: present them as one event that may be recorded twice, not as two, and ask. When they confirm, call `revise_event` on the record to drop with `same_event_as` naming the record to keep. The dropped record leaves the history and every count, and its evidence, people and notes go to the one kept. Then compare the two summaries and add to the kept record anything only the dropped one said. `separate_again` on the dropped record undoes it. Keep the record that was made first unless the user prefers the other.

When the user says a recorded event never happened, or was recorded by mistake (a call that was only planned, say), call `revise_event` on it with `remove_because` giving their reason in their words. Do not rewrite it into some other event to keep it, and do not remove a record on your own judgement because it looks thin or doubtful: tell the user what you doubt and ask. The record leaves the history and every count, and the audit trail keeps it with the reason. The result names what the record left as it was: the deal's stage, open tasks that came from it and notes on it. Put each to the user. A stage the event moved is set with `update_deal` once the user says where the investor stands, and a task that existed only because of the event is cancelled with `save_task`. `restore` puts a removed record back.

When catching up on several past events in one session (the first session of a new company, or after time away), each event is still one the user described or one you found in their mail, calendar or documents and recorded with `found_in`. The date and the outcome come from what the user said or what the message or calendar entry shows. Do not guess a date, and do not write an outcome the source does not contain: "expressed interest" is a claim about the investor, and it is recorded only when the user or the message said so. If the user knows an exchange happened and not when, ask for the day, and if they cannot give one, tell them it is not recorded.

Meeting notes, transcripts and spreadsheets in the user's documents are not something the user told you. Send each event a document says happened to `record_event` with `found_in` of kind `document`: the document's link or id, its title, its own words about the event as `excerpt`, copied exactly, and the date the document gives. Ray refuses one without the date or the words. It waits in Captures to Review, where the user sees the document's words beside your summary; tell the user what is waiting. An event the user then confirms to you in conversation is theirs, and is approved, not recorded again. A document records an event only when it says the event happened. A meeting planned for "tomorrow", a call that was scheduled, a firm someone means to approach and a target-list row marked "Not started" are plans, not events, and none of them moves a stage. Take the day from the document, or the latest day it allows (notes dated 23 September that mention a recent call put it on or before that day), and never send a time the document does not give. Write only what the document says: notes that a call was scheduled do not say the investor showed "strong interest". A transcription can garble a name (a fund heard as "an Enterprise AI fund"), so check a name against an identifier such as a website, an email address or a profile before creating a firm or person from it.

Use the context's current time and user time zone to interpret relative dates. Ray counts days in the company's time zone, which the context gives as `company_timezone` with `today`, the date there now: a due date before `today` is refused as past, and overdue and stale are judged against it for everyone in the company. Clarify genuinely ambiguous timing rather than inventing it. Once the immediate action is complete, a newly supplied identifier can trigger the focused research workflow.

## Commitments

A commitment is what an investor said they will do, and it goes on the investor's financial path with `record_commitment`: the investor, the state, the amount and the instrument by name. The round's `money.instruments` (in `get_fundraising_context` and `get_round_operating_view`) lists the instruments recorded, by the names a commitment uses: "on the SAFE" is the round's instrument called SAFE when it has one. Only an instrument that is not in that list needs `record_instrument` first, and then only with terms the user gave; never tell the user the round has no instrument without reading it. The states are indicated (they said they may invest), soft committed ("Ben is in", nothing signed), hard committed (a firm yes on an amount), allocated (given a place in a close), signed (the documents are signed), withdrawn (they pulled out) and lapsed (it expired). Funded is never set by hand: the money sets it (the next section). The example in the product requirements, "Ben is in for $250K on the standard SAFE. Treat it as a soft commit.", is one call: Ben's deal, `soft_committed`, 250000 and the instrument `standard SAFE`. Stated together with a meeting or a call, it goes as `commitment` in that `record_event` call, so one statement stays one call.

The first commitment creates the investor's financial path; later ones move its state, and every earlier state stays in the history, so "Acme has gone hard on it" is the same call with `hard_committed` and no amount: the amount of the previous state carries over. A withdrawn or lapsed commitment has no amount. A soft or hard commitment marks the investor committed, a withdrawal marks them withdrawn, and a lapse puts a committed investor back to active; do not also call `update_deal` for that. The expected amount is not touched, because it is the team's estimate and the commitment is the investor's word. A repeat of the same state and amount writes nothing.

The instrument is the round's. Record it once with `record_instrument` (a name, a type, and the terms when the user gave them: a valuation cap, a discount, the maturity date a note needs, the valuation or price a priced round needs), then name it in each commitment. A commitment that names an instrument the round does not have is refused; record the instrument first with what the user said, and ask for the rest only when Ray needs it. A SAFE is `safe_post_money` unless the user says pre-money. A commitment in another currency than the round's needs an instrument in that currency, and the round counts it without adding it in.

Both need `manage_financials`, held by owners and admins. When Ray refuses, say who can record it; do not put the amount in the expected amount or a note instead. With a meeting, Ray refuses the whole call; record the event without the commitment and say the commitment is waiting on someone who manages financials.

`get_round_operating_view` returns each investor's `commitment_state`, `commitment_amount`, `commitment_currency`, `commitment_instrument` and `commitment_signed_by`, and the round's `money`: `indicated`, `soft_committed`, `hard_committed`, `allocated`, `signed_not_yet_funded`, `funded`, and `remaining_to_target`, which is the target less what is hard committed, allocated, signed or received, counting each investor's money once (money that came before the signing is not added to the commitment it pays), with `closes` and the last ten `receipts`. `get_fundraising_context` returns the same `money` for every running round. The round page shows the Money card from the same figures, and the commitment in place of the estimate in the Investors table. Money in Ray is commitments recorded, never the cap table or the bank: report it by state ("$250K hard committed, $500K soft committed, $400K received"), never as "raised", and say nothing is received unless `funded` says so.

## Signing and money received

A close is the event at which signed commitments are counted and the money is called, and a round may have several. Record one with `record_close` when commitments are about to be allocated or signed against it: its name, the date it is planned for, what it is meant to raise, and `executed_on` once it has happened. Until then a planned close is a marker in the round's plan (`update_round`), not a close; "first close maybe early November" stays a marker. The same name again updates the close, and an executed date is not taken back. Closing the round itself at the final close is `update_round` with the status.

A signing is `record_commitment` with the state `signed`. The documents name three things and Ray needs all three: the instrument (named now or already on the path), who signs (`signed_by`: the legal name on the documents and whether it is a fund, the firm, a person signing personally, or a vehicle such as an SPV) and the amount (carried over from the hard commitment when not said). The entity is the one that signs and wires, never the contact met: Sarah Chen is the contact, "Acme Ventures Fund III, L.P." signs. Ray records the entity once and, when it is a fund, records the fund under the investor's firm. `signed_on` is the date the user gave, today otherwise; `close` names the close it belongs to. Once signed, a commitment is not moved back by hand, and nothing sets it to funded but the money. A signing recorded after money has already come is funded at once if the money covers the signed amount, and a signed amount corrected later (`signed` with the right `amount`, also on a funded commitment) moves it between signed and funded by the same rule; the result says which. `allocated` is a place in a close before signing, with `close`, and can still go back.

Money that arrived is `record_receipt`: the investor, the amount, the date it arrived, how it came (wire, ach, check, crypto, other) and the bank's reference whenever the user has it. Each receipt is one row that is never edited. The same reference is refused a second time, so always pass it when it is known; a receipt without one that repeats the same amount on the same day writes nothing. A receipt that brings what is received up to the signed amount marks the commitment funded; the result says so. A signing says the same of money already received, and when money that came before it is no longer a discrepancy. Money against a commitment that is not signed, or more than was signed, is recorded and reported as a discrepancy in the result and in `money.funding_discrepancies`; tell the user, and record the signing when they confirm it. Money that went back, or a receipt that should never have been recorded, is `reverse_receipt` with the receipt's refcode (from the result, `money.receipts`, or `search_crm` with the bank's reference) and the reason: the receipt stays, a negative receipt nets it out, and a commitment that was funded goes back to signed. A receipt is reversed once; a reversal is never reversed. When the money did arrive but Ray has it wrong (the wrong investor, amount, date, method or close: "the 8841 wire was Birch's, not Acme's"), use `correct_receipt` with the receipt's refcode, only what was wrong in `correction`, and the reason. It reverses the receipt and records the corrected one with the same bank reference, and the result lists both, so the money counts once and the reference stays with it; it also corrects a receipt that was already reversed for that reason. Report it as a correction in Ray, not money moving at the bank. Never invent a reference or drop it to get a receipt recorded again: `record_receipt` refuses a reversed receipt's reference and says to correct that receipt.

All of this needs `manage_financials`. When Ray refuses, say who can record it and do not put the amount in a note or an estimate. Report money received as received, by investor and date, and the signed amount still to come; the warning "target close approaching" on a round now compares the target with what is received, signed, allocated and hard committed, not with estimates.

## Choose the operation that matches the instruction

| User intent | Operation and completion rule |
| --- | --- |
| Plan or start a raise, or add an earlier closed round | `create_round`; planning amounts are targets, closed rounds require an actual closing date, and creation does not change other rounds. |
| Rename an existing round | `list_rounds`, then `rename_round` by refcode; only the name changes, and capture rules still apply. |
| State or revise what the raise is, or pause, close or reopen a round | `update_round`; send only what changed, use `clear` to remove a part, and send the narrative or the markers whole. Verify by reading the round. |
| State or revise what the company is: what it does, the problem, the product, traction, the team | `save_company_story`; send only the topics that changed, use `clear` to remove one, and read `company_story` back from `get_fundraising_context`. One story for the company; the raise stays on the round. |
| Explicitly change a deal's name, stage, disposition, amount, owner, priority, or waiting-on | `update_deal`; identify the existing deal, change only stated fields, use `clear` to remove an expected amount, and verify the returned record. Include pass reasons if supplied without holding up a stated pass. |
| Take a deal created by mistake out of the pipeline | `update_deal` with `archived: true` on its own and the user's reason, only when the user asks. It leaves the pipeline and every count with its history kept; the result names the open tasks that stay, for the user to cancel. `archived: false` restores it by refcode. Do not pass or withdraw it instead: those say the investor decided. |
| Name the round's instrument or its terms | `record_instrument`; a name, a type and the terms the user gave, once per round; the same name again updates it. |
| Add to or correct a recorded event, or make two records of one event into one | `revise_event` with the record's `version` as `based_on`; send the whole new summary or detail and keep what the record already holds. `same_event_as` on the record to drop, after the user confirms. Never a second record or a note. |
| Take out an event the user says never happened | `revise_event` with `remove_because` in the user's words, then ask about the stage, tasks and notes the result names. Never rewrite it into another event, and never remove one without the user saying so. |
| State where an investor's commitment stands | `record_commitment` on its own, or `commitment` inside the `record_event` call when it came with a meeting or a call; the state, the amount if said, the instrument by name. Report it by state, never as money raised. |
| Record a close of the round, or that it happened | `record_close`; the name, the planned date, what it is to raise, and `executed_on` once it has happened. A date that is not certain yet is a marker on the plan instead. |
| Record that an investor signed | `record_commitment` with `signed`, the instrument, `signed_by` (the legal name and type) and the close; the amount carries over. Not moved back by hand afterwards. |
| Record money that arrived, correct or undo a receipt | `record_receipt` with the amount, date, method and the bank's reference; `correct_receipt` with the receipt's refcode, what was wrong and the reason, when the money came but Ray has the investor, amount or date wrong; `reverse_receipt` with the receipt's refcode and the reason when it went back or should not have been recorded. Funded follows the money; nothing sets it by hand. |
| Create, change, or complete a standalone follow-up | `save_task`; tasks from an event belong in that `record_event` call. To move a task to another deal, name the task by its refcode and give the `deal`. |
| Correct contact details or employment | `save_contact`; omitted fields stay unchanged and explicit nulls clear supported fields. Preserve prior addresses and affiliations: end a job the person left. A job they never held, recorded by mistake, is removed with `remove: true` on its affiliation, and an address or number on the wrong record with `remove_profile_item`. |
| Keep commentary that fits no structured field | `add_note`; avoid repeating an event's summary. |
| Save a research list before outreach | `save_contact_list`; list membership creates no deals. Find candidates with `search_contacts`: `bio` phrases find what a bio says ("angel", "family office"), `on_no_list` finds who is still unsorted, and `not_on_lists` leaves out the groups already sorted. To change a few members, give the list's refcode or exact name with `add` or `remove`; a field left out keeps its value. The Lists page shows every list and its members. |
| Record a message with one text sent to a group | `record_group_message` once the user says it went out: the list, the subject and the members it went to. One record on no deal. See [Messages to investors](messages.md). |
| Record how two people know each other | `save_relationship`; use stated or sourced context, and do not infer strength from a shared employer or social follow. |
| Track an introduction | `save_introduction`; it records progress and may create or close a chase task. It does not contact anyone. When the user asked someone for introductions before anyone was named ("Sam will connect us with a couple of seed funds"), leave out `target` and say in `ask` who is wanted. When the introducer names people, give the first as the target of that introduction by its refcode and record each other one as an introduction of its own. Never invent a target, and never mark one sent before someone is named. |
| Register a deck, model, or data-room URL | `save_document`; preserve immutable versions with `previous_version`. It does not send the document. |
| Record materials already shared | `record_document_share`; identify the exact version, recipient, time, and channel. |
| Draft a message to an investor | `get_email_context` first; put its stops to the user, catch up from their mail and calendar with `found_in`, then draft. Ray sends nothing. See [Messages to investors](messages.md). |
| Save a reusable draft or sourced research summary | `save_content`; preserve versions and mark text approved only after the user approves that text. |

Read current schemas before supplying nested arguments. Use supported tool operations; do not invent tools for functionality absent from the catalog. Any actual sending or publication requires separate authorization and a capable tool.

## Proposals and retries

Apply the capture rules in the skill entrypoint to every write. A proposal is not a recorded event, completed task, stored picture, or created round. Resolve the existing proposal after approval. Keep identifiers from results so follow-up calls target the same operation or record.

After an uncertain network result, read the relevant state before repeating a mutation where possible. Do not change arguments to bypass duplicate detection or conflict checks. A validation error should lead to a correction grounded in the schema, not repeated guesses.

## Duplicate review

Use `find_duplicates` to identify candidates. Similar names suggest a review, not proof of identity. A new identifier can corroborate a match or reveal that two records represent different people. Resolve uncertainty before merging.

For an authorized merge of confirmed duplicates, preview with `merge_contacts` first, inspect conflicts and affected records, and commit using the returned token for that reviewed state. If the preview changes, review the new result before proceeding. Preserve source evidence and communication restrictions. Do not use merging as routine automatic enrichment.

## Notes on any record

Use the same note shape for people, firms, deals, rounds, and events: a required freeform `content` body and optional `metadata.title`, `metadata.tags`, and `metadata.sources`. A short personal note needs only its body. Keep research-specific labels, scores, concerns, and hypotheses in that body rather than inventing metadata keys. Tags organize commentary; they do not change permissions, contact facts, verification status, or pipeline state. Use existing structured operations when the user actually requests those changes.

A source needs a readable label. Include its public HTTP(S) URL when one exists; a local workbook, sheet and row or a user conversation can be identified by label alone. Never invent a URL to satisfy a schema. A saved source is attribution, not proof that its claims were checked.

To edit, read `get_note` first, then call `update_note` with the complete desired body and metadata plus the returned `updated_at` as `expected_updated_at`. Omitted metadata keys are cleared. If another edit intervened, reread and compare before retrying; do not overwrite newer work blindly. Capture rules and permissions apply to edits as well as additions. Keep versioned research deliverables in `save_content` when their existing workflow calls for versions.

## Attach round materials

When saving materials for a specified round, resolve that round and include its refcode in `save_document.about`. To attach an existing document, read its latest version and submit its unchanged title, type and URL with that refcode as `previous_version` and the round in `about`; this adds an association without another version. A changed title, type or URL creates a version. Verify the association by reading the round’s documents. Preserve sharing events on the exact version actually sent, even if a newer version now exists.