rem-investigate-org · git:20261010.f3bc74b · 2026-10-10 · sha256 7d919eb4a9073109
rem-investigate-org git:20261010.f3bc74bA
Immutable. This exact content never changes and is served at /api/v1/blob/7d919eb4a9073109.
--- name: rem-investigate-org description: The steps for investigating an organisation's page, composed after rem-investigate when the subject is under orgs/. --- # Investigating an organisation - The material includes mail on this page's domains and, when another domain page shares a canonical contact candidate, their dated primary correspondence. A shared page or display name is a lead, not identity proof. Verify the person and company from the messages before drawing cross-domain conclusions; keep uncertain address/domain ownership explicit. Do not merge legal entities. Existing notebook pages are context, not independent evidence. - Read the material for what is agreed with the **entity**: terms, dates, signed or unsigned documents, who decides. What is true of one person belongs on that person's page. - `People here` links existing people pages; never copy their contents. A person who writes from the domain but has no page: name them, do not create a page. - `Terms` holds the numbers (rates, dates, notice periods) with the mail or attachment that states them; search attachments for them first. - Compare offers and replies by date and exact terms. An accepted credits/tier offer does not establish acceptance of a distinct free-month offer, provisioning or completed setup. A later request on another topic does not close a thread. - Lead `Our relationship` with the current supported result and next uncertainty, before the introductory history. Preserve ambiguous scheduling language; do not infer a broken link or who supplied it. A shared subject is not a verified thread. - A vendor that only ever sends, or the user's own domain, is not a relationship; say so in `Uncertainties` rather than filling `Our relationship`. ## What to produce Follow `rem-page-org` exactly, every section present, in order. - Keep Facts dates scoped to confirmed target-domain correspondence when cross-domain identity remains unverified. Put candidate-domain dates in explicitly qualified related context instead.