RISE Reduce — Terms of Service

1. The agreement

[AWAITING COUNSEL]

2. Licence grant and term

[AWAITING COUNSEL]

3. Fees, metered usage and billing

[AWAITING COUNSEL]

4. One organisation, one account

[AWAITING COUNSEL]

5. Verification of plan limits

[AWAITING COUNSEL]

6. Customer data and restoration

[AWAITING COUNSEL]

7. Warranties and disclaimers

[AWAITING COUNSEL]

8. Limitation of liability

[AWAITING COUNSEL]

9. Termination

[AWAITING COUNSEL]

10. Governing law and disputes

[AWAITING COUNSEL]

PRODUCT FACTS SUPPLIED TO COUNSEL — NOT TERMS

• Restoration of a customer's own data is NEVER gated by licence state, expiry, payment or entitlement. There is no circumstance in which non-payment prevents a customer reading their own files. A RISE file that has been tampered with refuses to open (founder ruling 22, 2026-09-14): that is the file's integrity failing closed, not a gate on restore, and restore itself is never blocked. Where a drafted clause needs a RISE file's identity to be protected against tampering, it names sealed RISE files: a plain RISE file protects its identity only with a checksum (the same ruling). Any drafted remedy for non-payment must not contradict this.
• The software runs on hardware the customer controls. It is CPU-only, uses no trained model weights, and makes no external AI call at runtime.
• Restoration is byte-exact or it refuses. The product never returns an approximate, degraded or guessed value.
• Every RISE file the product has ever written continues to open, unless it has been tampered with (founder ruling 22). Readers are only ever added, never removed.
• Usage is metered in saved GB-months and priced on ONE published table of marginal bands, identical on every plan; nothing multiplies a band rate except the premium on usage above a plan's cap. Nothing is deleted: the bytes remain and restoration is byte-exact. HQ recomputes the billed quantity from evidence rather than accepting the appliance's own figure, and the recompute is conservative — it under-bills rather than over-bills where evidence is missing.
• Term pricing is a discounted RATE, not an enforced commitment: nothing sets a Stripe cancel_at, and the term is billed monthly. Early cancellation is priced by src/money/earlyCancellation.ts (founder ruling #15, which superseded the R-C re-rate that src/money/clawback.ts implemented; earlyCancellation.ts still takes the monthly term rate from clawback.ts licenceMonthlyRate, which since 2026-09-15 refuses a negotiated base that is not a whole number of cents): the licence fee for the months actually used, at the rate for the term actually completed, capped at the whole term at the signed rate, raised once as a draft invoice; nothing is added to the months used (founder ruling 2026-09-24 removed the three exit-notice months); the usage charge is never clawed back. A monthly plan has no minimum term and no exit charge. Nothing in HQ computes a pro-rata credit or refund of unused term.
• THE PLAN CARD §2 AND §3 MUST MATCH (founder rulings 2026-09-13/14). Seven plans: Micro, Starter, Entry, Standard, Business, Fleet and Air-Gapped. Micro through Business are single-licence: one licensed installation each, meaning one licence, one usage meter and one active machine at a time, with failover to a standby machine spending the licence's existing allowance of machine moves; a second installation at the same time is Fleet. Fleet and Air-Gapped pool any number of installations under one base fee and one walk of the bands (founder ruling 2026-09-14: no installation limit). Caps are counted in saved GB-months — Micro 3,072, Starter 17,408, Entry 102,400, Standard 512,000, Business 1,048,576 — and Fleet and Air-Gapped are uncapped with no surcharge. Above a cap service never stops: usage is billed at 2 times the band rate on Micro and 1.35 times on the other capped plans. Micro is sold monthly only. The engineering draft defines an installation as a machine a licence is activated on for reduction, because activation is what HQ records (src/http/activateRoute.ts); a machine that only restores or reads is not one.
• COPIES ARE FREE (founder ruling 2026-09-13/14, restated as billing pass 3 ruling 22: copying a RISE file is never billed), the constraint on §3: RISE charges once, when data is reduced. Copies, backups and replicas of RISE files are never charged. Reducing the same original data separately on several servers is several reductions. This replaces every earlier duplicates-count-once, cross-server-dedup or shared-blocks-counted-once statement. MEASURED 2026-09-14, AND WHAT IS NOT: HQ meters each licence's check-ins, which carry whole-estate logical and stored byte totals and no per-file figure (src/wire/ping.ts), so HQ cannot itself tell a copied RISE file from an original, and the same data reduced on two installations arrives as two licences' readings. Whether an installation counts a COPIED RISE file it finds in a folder it manages as saved bytes is engine behaviour and was NOT established by the terms lane. The website draft states the rule in two marked strings (Refund Policy and Terms).
• MICRO ABOVE ITS CAP CLOSES ON MICRO'S OWN 2x TERMS — AT EVERY VOLUME MEASURED SINCE THE THIRD FIX OF 2026-09-14 (re-measured 2026-09-14; this fact said until then that Micro above its cap could not be billed, which stopped being true for most volumes when src/money/close.ts began reading the per-plan overage on 2026-09-13). vendor/pricing.js prices Micro at 4,000 saved GB-months at $53.06 of usage (usage_ladder_v2.overage.by_plan, Micro premium fraction 1.0), close.ts takes the premium from the same per-plan terms (P.overageTerms), and its month close walks that month to 5,306 cents at a premium fraction of 1,000 milli; Starter at 20,000 saved GB-months comes to $324.70 (32,470 cents). TWO FURTHER CLOSE DEFECTS WERE FIXED ON 2026-09-14, and the first version of this fact overstated one and missed the other. (1) close.ts's two sub-total checks rounded a float against pricing.js's integer cent, so it refused SOME months whose exact usage lands on a half cent — not all of them: in the first band alone (1 to 3,072 saved GB-months) 19 of the 307 half-cent volumes were refused (among them 305, 645 and 675) and the other 288 closed; over every plan at 0 to 20,000 saved GB-months plus 4,098 larger and fractional volumes the check refused 1,010 correct months before the fix and none after. (2) Both stores refuse a row whose overagePremium float is not exactly the float they rebuild from the stored whole-cent column, and close.ts copied pricing.js's float instead of rebuilding it, so correct ABOVE-CAP months were refused on every capped plan, Micro included: through closeMonth and the in-memory store, 161 of 13,069 closes on all seven plans refused before (Micro 22, among them 3,139 and 3,152 saved GB-months; Starter 79; Entry 35; Standard 11; Business 14) and 0 after. test/card2026_09_13.spec.ts posts a Micro month above its cap, half-cent months and above-cap tie months through closeMonth and the in-memory store. NOT ESTABLISHED by these measurements: that a Micro threshold crossing and a Micro monthly statement have been exercised end to end, or that a Micro purchase has been completed end to end (checkout sells micro since 2026-09-14, src/http/checkout.ts CHECKOUT_TIERS).
• A PLAN MOVE IS OPERATOR-REVIEWED AND NEVER AUTOMATIC (founder ruling 2026-08-15, restated 2026-09-13). The crossing is named on the monthly statement (the usageThreshold frozen onto the invoice mirror). HQ has no verb that changes a plan: a recorded decision is an authorisation that a person then carries out. MEASURED 2026-09-14 BY READING src/http/consolePage.ts, AND IT CORRECTS WHAT THIS FACT SAID UNTIL THEN: the console does not wait for a statement that carried THE CROSSING UNDER REVIEW. It takes the earliest issued statement that carried ANY threshold notice for the customer and refuses a move only until one billing cycle after that statement (src/money/upgradeReview.ts planMoveEarliest), so a notice from an earlier, already-resolved review can allow a move on a new crossing before that crossing has appeared on any statement. A §3 promise that no move happens before the customer has been told about the crossing is therefore not kept by the software today; the website draft marks that sentence as awaiting counsel for that reason.
• ONE ORGANISATION, ONE ACCOUNT, ONE PLAN — the constraint on §4 (founder rulings 2026-09-13/14; FINAL rulings 9 and 10 of 2026-09-14). RULED: new purchases are matched on a verified company email domain, the tax ID and the payment-method fingerprint (a personal email domain matches on the last two only); check before charging, ask and do not assume; checkout asks who the licence is for; the card is saved and fingerprinted before any charge and matched first; a card already on another account, for the buyer's own organisation, is answered 'This card is already used by a RISE account. Sign in to add this plan to that account, or tell us this purchase is for a different organisation.' with no charge until the buyer chooses; a card on another account for another organisation is allowed, and that organisation's contact confirms their email with a code before the licence is issued; an organisation that already has an account is told '[Organisation] already has a RISE account. This plan can be added to it.'; nothing is said to an unconfirmed visitor about a company, a domain or a tax ID; a hold happens only for a match found after payment, with the public status text 'Payment received. Licence on hold: possible duplicate account. We'll contact you within 2 business days.', an email that names the match only when the buyer controls it and offers two actions, and a person deciding within 2 business days; a hold never affects an issued licence on either account and never revokes a grant; a release as a separate organisation records a payer link; a real duplicate is moved by a person who decides any refund or credit, and nothing moves automatically; a release mints a fresh activation code. BUILT (read by the terms lane; the sign-up storage measured 2026-09-15 on the real routes with the in-memory store and the Stripe test double): src/http/checkout.ts (the 6-digit email code every buyer confirms, the business-email rule, verifiedEmailUpgradeMatch on the confirmed domain as the pre-payment account answer, joined in round 6 by the ruling-15 refusal of a second Air-Gapped licence at the same three doors, the setup-mode card check at GET /checkout/card, the contact code for another organisation); src/webhook/processor.ts (a checkout completion, a bank-transfer settlement or a charge.succeeded is matched against every other account; only a purchase not yet issued is held; a match that reaches an issued licence writes account_match_after_issue for a person; the held buyer is emailed the ruled text; a purchase for another organisation waits for its contact); src/http/console/accounts.ts (release with a fresh code and the payer link, or refuse, each by a named operator with a basis; the age of every open hold). No tax ID and no machine is looked up before payment. WHAT AN ACCOUNT IS RECORDED UNDER, AND LOOKED UP UNDER, CHANGED AGAIN ON 2026-09-20 IN ROUND 6 (read this round in src/money/accountMatch.ts, and this paragraph is the accounts lane's own filed correction to what round 5 left here): an account is recorded under the EXACT host of the address whose code was read (verifiedDomainKeyOf), and a later buyer is matched to an account only on a name somebody PROVED — their own host, a host theirs sits under (domainMatchCandidates), or a host that sits under theirs (provedNamesUnder). Round 5 walked parents only, which is what left founder ruling 15 with no enforcement point. A host that SHARED_NAME_MIN_ACCOUNTS (2) or more DIFFERENT accounts have proved names beneath — how a registry or a hosting apex looks — is treated as a shared name and is matched in neither direction (hostIsSharedName). ROUND 6 OF 2026-09-20 CORRECTED THE CLAUSE THAT FOLLOWED, which this fact and the website's twin both carried as an unqualified exemption for the buyer's own exact host, 'because it is their own proof'. That is true of the EXACT-name look-up and FALSE of the child direction, and the round-6 review measured it. MEASURED AGAIN HERE (scratch billing3/terms/r6f/probes/p2_match.mts, the real organisationDomainMatch on MemoryStore): with cus_apex proving mycorp.example and cus_t1 and cus_t2 proving one.mycorp.example and two.mycorp.example, a buyer at mycorp.example answers matchedCustomerIds ['cus_apex'] and sharedNamesDropped ['mycorp.example'] — the exact match survives and the CHILDREN ARE DROPPED ON THE BUYER'S OWN HOST, because accountMatch.ts:513 guards only the parent candidates with `name !== self` while :521 pushes `self` into `dropped` and skips the child walk once SHARED_NAME_MIN_ACCOUNTS is reached; with ONE account beneath instead of two the same buyer answers ['cus_apex','cus_t1'] and drops nothing. SO, EXACTLY: an account recorded under the buyer's exact host is matched whether or not that host is shared; an account recorded UNDER their host is matched only while fewer than two different accounts have proved names beneath it; an account recorded under a host ABOVE theirs is matched only while that higher host is not shared (a buyer at z.host.example, with cus_x and cus_y beneath host.example, answers [] and drops host.example). HQ now records a company e-mail domain for ANY host that is not on its own list of registration suffixes, including a two-label host such as gen.io: round 5 called every two-label host with a generic second label a suffix and so recorded nine business-shaped domains as nothing at all. Two organisations that merely share a registration suffix such as uk.com are still two organisations, and a purchase for ANOTHER organisation still writes no domain on the payer's account at checkout or at activation. On a plan added to an existing account because the buyer confirmed an address at that account's domain, Stripe's subscription page is sent customer_update name 'never', so that buyer cannot rewrite the account's billing name; the address stays 'auto' because Stripe Tax rates against it (src/http/checkout.ts; NOT measured against real Stripe). CODE BEHAVIOUR NO RULING STATES, FOR THE FOUNDER: a held, withheld or refused purchase's subscription keeps billing until a person acts in Stripe (invoice_paid_while_held facts); the held-purchase notice goes to the address the licence carries, which on a purchase for another organisation is that organisation's contact and not the payer (src/webhook/processor.ts orderLicenceEmail, enqueueHeldPurchaseNoticeOnce); 'the plan goes onto that account' is implemented for the buyer's own organisation as the Stripe pages opening on the oldest matching account's customer, and for another organisation as a record for a person while the subscription stays on the payer. Accounts created before migration 20260914120000_accounts_one_org_one_machine have no signal rows and none are backfilled (founder ruling 2026-09-14: no migration of existing licences). A MATCH IS NOT A SPLIT DECISION: HQ still cannot detect a customer who split deliberately (src/money/customerGroup.ts), so §4's anti-split correction remains a right that a person exercises.
• ONE ACTIVE LICENCE PER MACHINE, ACROSS ALL ACCOUNTS (founder rulings 2026-09-13/14; FINAL ruling 10d of 2026-09-14: the machine match on every activation and move refuses a machine that already runs another account's licence, with a named reason and an operator override; ruling 11: on every bind and every move). BUILT (read, not run, by the terms lane): src/http/activateRoute.ts bindUnderMachineLock takes a per-machine advisory lock and, on every first bind and every move, refuses with machine_runs_another_accounts_licence (and an open machine_account_match_refused fact) when a licence of ANOTHER account is bound to the machine in a holding state (active, active_provisional or freeze: MACHINE_HOLDING_STATES in src/money/accountMatch.ts), and with machine_has_another_active_licence when a licence of the same account holds it, unless a live MachineLicenceOverride covers THIS licence on THIS machine. A machine another account only used before is not refused, and its stale binding is released. No activation holds a purchase any more. src/lifecycle/derive.ts returns freeze for an unresolved revocation, a payment failure unresolved for 7 days or an open dispute before it asks whether a lease exists, so a licence with no lease can still hold a machine. /activate refuses, before any bind, a licence whose issuance is withheld (issuanceHeldForReview: an open review, an organisation contact still to confirm, or a second Air-Gapped licence withheld under ruling 15). An operator grants or revokes an override with a basis at /console/accounts. A successful bind releases every other licence's binding to that machine that no longer holds it, so a lapsed licence must activate again. HQ records one device fingerprint per licence (License.deviceFp, moved only by a rebind within DEFAULT_REBIND_ALLOWANCE in src/db/store.ts, which an operator can raise); activateRoute.ts records that the fingerprint's inputs are administrator-settable, so what HQ holds is a record of activation, not proof of one physical machine, and no drafted clause may say a licence is bound to a machine.
• AIR-GAPPED (founder rulings 2026-09-13/14 and billing pass 3 rulings 14-17). RULED: a prepaid deposit covering ONE QUARTER OF THE WHOLE BILL, three months of base fee plus three months of expected usage, a deposit and never a cap (14); uncapped with no surcharge; a signed usage report every quarter with 30 days' grace; each report renews the lease; the pooled count close for a multi-licence customer, and no second Air-Gapped licence sold to one customer until it passes (15); months before a customer's first accepted report never count against the report schedule, in any quarter (16), and they ARE billed from activation (founder confirmed 2026-09-24); a late report is always accepted and renews the lease, including after the licence was released from its machine, and a lapsed lease pauses new Reduce only, restore and reading never blocked (17); no installation limit (founder ruling 2026-09-14). BUILT (read; the schedule and the deposit measured 2026-09-15 on synthetic inputs): src/money/airgapQuarter.ts airgapQuarterDeposit sums every Air-Gapped licence fee at its own term price and negotiated base for three months, plus three months of expected usage taken, in order, from the Air-Gapped licences' last closed billing periods, the accepted usage reports (each month walked once across licences), the lower end of the range stated on the sign-up form, or none; rounded once; refused for a customer with no Air-Gapped licence (measured: a monthly-term licence with no history gives 833,100 cents; the stated range 10 TB to 100 TB adds three months at $143.36 — on the card as amended 2026-09-27 that lower end walks to $59.39 a month, arithmetic from the tranches, not re-measured). airgapReportSchedule: quarter 1 is the partial UTC month of the first lease plus three whole months; a count counts for its month only if received after the month ended; months before the licence's first ACCEPTED report (the earliest received, whatever its sequence) are excused in any quarter, applied PER LICENCE, and a later report for an earlier month does not move that line; before any report nothing is excused; an operator may excuse a month at /console/accounts; quarters count consecutively; a quarter's report is due on the 1st of the following month with 30 days' grace; the lease runs to the grace end of the next unreported quarter. src/airgap/count.ts judges a sequence per month and records a count only from a machine the licence is or was bound to, so a late report is accepted after release. src/grants/leaseRenewal.ts renews a live, active lease to the schedule end unless the licence is held or in dunning, and after a lapse re-issues (airgap_report) for a licence whose derived state is none (not paused, not cancelled) and that has an accepted report, unless held or in dunning; src/grants/mint.ts refuses that re-issue when the latest lease was provisional; a paid invoice renews no Air-Gapped lease. src/airgap/pool.ts prices every Air-Gapped licence of one customer as one walk per period, in tranches; its verdict runs the close against an independent band-table oracle and passed when run 2026-09-15; src/http/checkout.ts and src/webhook/processor.ts withhold a second Air-Gapped licence while it fails. ROUND 6 OF 2026-09-20 CHANGED WHERE THAT ANSWER FALLS, and this fact is updated for it: the refusal now runs at THREE pre-payment doors — POST /checkout on every account the buyer's confirmed domain matches in both directions (409 second_airgap_licence_not_sold, before any Stripe page), GET /checkout/card on the accounts the buyer's saved card matches, and POST /checkout/card/sign-in on the account the buyer signed in to — and it runs BEFORE the ruling-9c 'this plan can be added to it' answer, because that sentence cannot be kept for this tier. Nothing is charged at any of the three. After payment the processor withholds on accountsSharingOrganisation rather than on one Stripe customer id, because checkout opens a new customer per order. THE THREE REFUSAL PAGES ARE NOT RULED TEXT and are in the accounts lane's founder items. BUILT 2026-09-24 (HQ wave, lane H-close; src/money/usagePosts.ts billAirgapUsage): each accepted monthly report of a lone Air-Gapped licence, and each priced tranche of a pooled estate, is posted to Stripe as a pending invoice item for the month it covers; Stripe applies the customer balance, where the Reserve load holds the prepaid deposit, before it charges anything, so the deposit is drawn down first and only a shortfall is charged, on the same invoice. The next quarter's deposit top-up is recorded as due (src/money/airgapQuarter.ts airgapDepositTopUp) and nothing collects it yet. A report for a month before the licence's first accepted report is billed too: the code reads ruling 16 as governing the report schedule only, and the founder CONFIRMED that reading on 2026-09-24 — months before a licence's first accepted Air-Gapped report are billed from activation. WHAT THE CODE BILLS IS NARROWER THAN THOSE WORDS: a month's usage is posted only when an accepted report for that month exists, so a month whose report is never received is never billed, and ruling 16 means nothing requires the reports of the months before the first accepted one (read from billAirgapUsage, not run by the terms lane; test/hqwaveClose_2026_09_24.spec.ts measures that such a report, once accepted, is posted for its own month). The Terms draft says exactly that — usage in the months before the first accepted report is billed like usage in every other month since activation, when RISE accepts a report for one of those months, drawn first from any prepaid deposit held in the Reserve balance — and does not say that every such month is billed. Whether HQ must require, estimate or otherwise bill a month that is never reported is OPEN for the founder. Nothing requires the deposit before a licence is issued, and src/http/reserveRoutes.ts records that no in-repo flow yet mints the link tokens those routes need once LINK_SIGNING_SECRET is set. What the engine does with an expired grant is engine-side: airgapQuarter.ts cites the engine refusing compression on an expired grant and invariant I25 for restore never being gated by expiry, and the terms lane re-measured neither.
• AN ENGINEERING DRAFT OF §4 AND §5 EXISTS AND IS NOT COUNSEL'S TEXT. It is in the website's Terms of Service source file (rise-legal.js, document set version 2026-09-24), whose own header forbids publishing it until named site gates pass, with matching changes to that site's End-User License Agreement, Privacy Policy and Refund Policy; every paragraph in it that reserves a right or creates an obligation is marked as awaiting counsel. PARAMETERS THE FOUNDER RULED (the billing pass 3 rulings file, which is final), as the draft applies them: a 12-month anti-split look-back before the first written notice; 30 days to respond after that notice; control means more than half of the voting interests or the power to direct management, excluding holdings by investment funds and governments; the combined bill uses the highest-fee plan among the accounts, licence fees are excluded, the months are netted into one corrected invoice, and the customer has 30 days to dispute the figures; 60 days to cure a split by moving to Fleet or down to one installation, after which Fleet terms apply, and the Fleet remedy never applies to Air-Gapped customers; audits at most once in any 12 months plus one follow-up to confirm a shortfall was corrected, on 30 days' written notice, with a 12-month look-back, 30 days to supply records, records only and remote, never data contents; the customer pays RISE's reasonable audit costs only when the audit finds a breach of the plan rules worth more than one twentieth of the usage charges for the audited period, and ordinary meter rounding or measurement variance never counts toward it; a refused or late Air-Gapped report gets 30 days' grace; a corrected invoice may be issued 30 days after written notice, without waiting for the affected months to end (ruling 20). DRAFT PARAMETERS THAT ARE NOT IN THE RULINGS FILE (engineering's, added to answer review findings, for the founder and counsel to accept, change or reject): the highest-fee plan and the licence fees compared are monthly list prices before any term discount; neither look-back reaches a month before the customer accepted a version of the Terms containing the rule; the split question is raised only on a reasonable basis stated in the notice and no more than once in 12 months about the same accounts unless an account involved opened after the earlier notice; the decision is recorded with its reason and given in writing; the ruling-20 corrected invoice covers the affected months that have ended when the figures are sent, its 30 days run from the written notice of the figures, and how months still affected after it are billed is left undecided; the 60 days do not run while RISE is arranging a move the organisation asked for or cannot put Fleet into service for it; an organisation holding an Air-Gapped account is brought together into one account instead of being moved to Fleet; what a breach is worth is the shortfall in the charges for the period verified against what the rules would have produced, and the audit costs a customer pays never exceed that worth; nothing under these rules ends the licence automatically, drafted as an exception to the EULA's automatic termination on material breach; an installation is a machine a licence is activated on for reduction, and a machine that only restores or reads is not one; verification uses defined account, licence, installation and metering records, never anything on the Privacy Policy's list of what RISE never receives, uses the Air-Gapped reports already recorded and asks only for missing months; verification material is confidential; a metering difference is never billed back by a verification; the person accepting the Terms confirms authority for the organisation named in the order; ADDED 2026-09-20 after a review found them listed nowhere — reducing the same original data separately on several servers is several reductions (a billing rule, stated in both documents' copies-are-free paragraphs and in the COPIES ARE FREE fact below, which the rulings file does not contain); and a corrected invoice the customer disputed issues only after a person at RISE has reviewed the dispute and answered it in writing, which goes beyond the ruled 30 days to dispute. CODE BEHAVIOUR THE DRAFT DESCRIBES THAT NO RULING STATES (for the founder): a held, withheld or refused purchase keeps billing until a person acts in Stripe; a match on a licence already issued is recorded for a person and never held; the plan-goes-onto-that-account step as the ONE ORGANISATION fact describes it; ruling 16 applied per licence; an Air-Gapped deposit with no history priced from the lower end of the ordered range; Air-Gapped usage posted to no invoice; the organisation contact's confirmation issuing a new activation code; ADDED 2026-09-20, each read from the code this round — the ruled status text of ruling 9e has a second opening, 'Bank transfer in progress', while a transfer is still settling (HOLD_STATUS_TEXT_TRANSFER_SETTLING in src/money/accountMatch.ts), which 'exactly' does not cover; an operator may excuse an Air-Gapped month for which the software wrote no report (the airgap_month_excused fact, src/money/airgapQuarter.ts); the held-purchase notice goes to the address the LICENCE carries (src/webhook/processor.ts orderLicenceEmail), so on a purchase made for another organisation it reaches that organisation's contact; nothing in the order or issuing flow takes the Air-Gapped deposit — airgapQuarterDeposit is called only by src/http/reserveRoutes.ts; when an invoice's total is not its subtotal plus its exclusive tax, which a customer-level coupon or credit applied in Stripe produces, HQ issues NO invoice and NO receipt for that month (409 and nothing printed on those four surfaces, src/documents/servedUsage.ts mirrorTotalsGap), rather than printing a total it cannot derive; and a served invoice or receipt whose detail runs past two pages is still served and says on the page that it does and how many rows it has. ADDED 2026-09-20 IN ROUND 5b, after a review read three more code paths this lane had described from the wrong end: (a) THE PAYER IS SENT A SECOND COPY OF THE HOLD NOTICE ON ONE PATH — src/http/checkout.ts:2471 and :2477 enqueue two notices in the same transaction when the organisation contact's confirmation finds a match, the contact's and the payer's, the payer's under the email key code-held-payer:<licence> with buyerConfirmedEmail null; that copy names nothing, but the round-5 claim that such a copy always names nothing is false, because heldPurchaseNoticeLines (src/money/accountMatch.ts:959) names a payment_fingerprint match unconditionally and the charge path passes buyerConfirmedEmail null with exactly that kind; (b) A STATEMENT IS STILL PRODUCED AND EMAILED FOR A MONTH WHOSE TOTAL DOES NOT FOLLOW FROM THE RECORD — the two /statements routes answer 409 and SEND the rendered body (src/http/documentRoutes.ts:819-844), src/webhook/processor.ts:2783 renders it and :2814 enqueues the e-mail with no gate on the refusal, and src/email/templates.ts renderE3Unprovable prints no table, no amount and no total; its PDF is refused with the invoice (src/documents/statementAttachment.ts), so nothing is attached and the only link it carries is the Stripe billing portal — never a RISE invoice or receipt link, which 'arrives link-only' was loose enough to be read as, and which round 6 of 2026-09-20 corrected — and 'no statement at all' was wrong; (c) A SERVED DOCUMENT COVERING SEVERAL CLOSED MONTHS PRICED ALIKE prints them, when the per-month form would not fit two pages, as ONE band table naming the run of months it spans, and a merged table is always one consecutive run (src/documents/servedUsage.ts, src/documents/usageBasis.ts mergedUsageDocLines — this fact cited src/money/usageBasis.ts, which does not exist, until round 6 of 2026-09-20), a presentation that source itself calls the nearest reading of ruling 7 and not ruled; (d) WHEN A PERSON MOVES AN OWN-ORGANISATION PURCHASE onto an existing account and the move empties its account, every AccountSignal row of the emptied account is re-homed onto the account moved onto, in that transaction (src/http/console/accounts.ts rehomeOrganisationSignalsAfterMove, HqStore.moveAccountSignals), which ruling 10c does not state and which section 3 of the privacy notice now discloses. ADDED 2026-09-20 IN ROUND 6, read this round: (e) RISE'S OWN DOCUMENTS ARE ALSO REFUSED FOR A MONTH WHOSE MONEY ADDS UP but whose band detail cannot be rebuilt from the frozen month-close record (src/documents/servedUsage.ts composeServedLines: a ladder-shaped usage month with no frozen record, a record still open, a customer-group allocation, or a close line disagreeing with the record). The invoice and receipt surfaces answer 409, and src/http/documentRoutes.ts e3InputFromMirrorServed strips invoiceUrl and receiptUrl and sets documentsRefused so src/email/templates.ts prints DOCS_REFUSED_NOTE in their place; the statement keeps its amounts and its total. The accounts lane wired that adapter into src/webhook/processor.ts this pass, so the emailed copy takes the same path as the served one; (f) A SECOND AIR-GAPPED LICENCE IS REFUSED BEFORE PAYMENT, in place of the ruling-9c answer, at three doors and in three pages of wording no ruling sets — see the AIR-GAPPED fact above; (g) ON BOTH REFUSAL SHAPES THE CUSTOMER MUST ASK — ADDED IN THE FINAL ROUND OF 2026-09-20, because the website draft's first attempt at (e) said the opposite and the review caught it. Neither e-mail promises RISE will send anything. DOCS_REFUSED_NOTE (src/email/templates.ts:440) reads '...and if you want RISE's own copy, write to us and a person will look at it', and renderE3Unprovable (:498-533), the totals-gap variant, reads 'Write to us and a person will look at it.' A walk of every .ts file under src/ for a verb that would mail RISE's own invoice or receipt — send-invoice, resend-statement, resend-documents, email-invoice, email-receipt, mail-invoice, send-paperwork, each searched in camel case; the exact patterns are in test/legalRulings_2026_09_15.spec.ts, which runs the same walk — returns ZERO HITS, so no mechanism sends RISE's own invoice or receipt on either shape, asked for or not — a person would have to produce it by hand. MEASURED 2026-09-20 by rendering both variants (scratch billing3/terms/r6f/probes/p1_paperwork.mts, output out/p1.txt). No clause in the draft may say RISE sends the paperwork, and none does now.
• WHAT §4 AND §5 WOULD RELY ON THAT HQ DOES NOT DO (read 2026-09-15). Nothing records a split decision or treats two accounts as one: the only verb that moves group membership, setCustomerGroup, has no HTTP caller (src/http/console/groups.ts). Nothing issues a corrected invoice for past months, and nothing computes the Fleet-terms comparison. Nothing records a written notice, a dispute or a verification, so no clock in either section (30 days to respond, 30 days to dispute, 60 days to cure, once in 12 months, the look-backs, 30 days to supply records, the ruling-20 30 days) is kept by software. A Fleet or Air-Gapped licence with no customer group tag receives its grant without a lease document while the usage ladder is active (src/grants/leaseV3.ts, refusal group_unbound_pooled_tier, recorded on the grant by src/grants/mint.ts), and a close that pools several customer records on unsigned membership refuses at gate 4_group_scope_G5 (src/money/close.ts). POST /activate itself binds any plan; vendor/activation_preflight.js is a release check run by hand that nothing at runtime imports. Whether a Fleet or Air-Gapped installation can reduce without that lease document is engine-side and was not established. Every remedy counsel drafts has to be one a person performs, and the Fleet remedy can only be offered once Fleet can be put into service.
• WHAT CHECKOUT RECORDS AS ACCEPTANCE OF THIS DOCUMENT (the sign-up form, founder 2026-09-14; measured 2026-09-15 on HQ's real routes with the in-memory store and the Stripe test double). The order page requires a ticked box reading 'I accept the Terms and I'm authorised to on behalf of [organisation]' and refuses the order without it. The SignupOrder row records the accepting name, email address and organisation, the time, and THIS document's manifest version and SHA-256 (legalManifestEntry('terms'), measured as version 0.0.0-draft). A completed sale writes a ConsentRecord with the same version, digest and time, with its IP address and user-agent columns empty. The Stripe subscription session carries the same version and digest as metadata, and Stripe's own tick-box is added only when RISE_TOS_URL attests that the Dashboard's Terms URL is set. Under NODE_ENV=production POST /checkout refuses every sale while this document is not in force (src/http/checkout.ts:1185, a 503), so no SALE completes against placeholder text. IT DOES NOT MEAN NO BUYER IS ASKED, and this fact said until 2026-09-20 (round 5b) that it did: src/http/buyPage.ts:592 renders the required checkbox in every environment, :975 refuses a client-side submit without it and :986 posts acceptTerms true, so a buyer is asked to tick the box against ten placeholder sections and the refusal comes after the tick. The text counsel delivers therefore has to be the text of this document for an acceptance record to cite it; the website's draft carries its own set version, which checkout does not record. WHERE THE BUY PAGE LINKS THIS DOCUMENT, corrected 2026-09-20 in round 5b after a review read the page: src/http/buyPage.ts:351 builds legalLinks from legalManifest() and renders them in the form's fine print (:749) and in the footer (:754). THERE IS NO TERMS LINK BESIDE THE CHECKBOX — :592 is plain text and lines 560-620 carry no href — so the round-5 sentence here, which cited buyPage.ts:350 and said the link beside the box pointed at this document, was a false reading of the page and was published inside this document's canonical bytes. The website's set version is recorded nowhere either way. The website's 'Agreement to terms' sentence was rewritten that day to name the served document and to say that the website text is a draft of it and not it. That makes the website honest; it does not make it the agreement. Until counsel's text IS this document's text, an acceptance record names ten placeholder sections, and no drafted clause anywhere may rest on the customer having accepted 'a version of the Terms containing this section'.