A comparison that only lists your wins is a brochure.

For advertising and sponsorship sales inside a school publication, yes — that lane is wired end to end and sits behind two navigation entries. For general district prospecting, partly: the prospect board, the activity timeline, the contact model, the forecast and the account read are all reachable, and the deal detail screen that owns every deal EDIT is reachable only by typing its URL. Account creation has no browser screen at all. That is the honest shape of it, and the built-not-switched-on list on the what you can reach page is the full accounting.

Because nobody wired the write. The endpoint exists, it enforces one account per studio per directory row and returns a conflict on the duplicate, and the browser client carries only the two reads. We could have described the endpoint and let you find out. Naming it here costs us a sentence and saves you a week.

No, and the precise answer is more interesting than the no. There is a spine and no engine: a cadence table with row-level security, a pure resolver that turns a cadence definition into ordered steps, a sequence step type, and isolation tests over both. There is no endpoint that runs one, no screen that builds one, and nothing anywhere in the application that calls the resolver. Nothing sends anything. Worth knowing how we know that, because it is the same reason to trust the rest of this page: the first draft of it claimed a total absence, which was true when it was measured and stopped being true two commits later, while the page was being written. We re-measured rather than shipping the sentence. If multi-step outreach automation is your requirement today, a general CRM has it and we do not.

The school. The district is resolved ABOVE it rather than being a second kind of account you also maintain, because in a district the money and the signature and the person you actually talk to are frequently at three different levels. The roll-up walks upward: this school’s district identifier, every sibling school under it, and the summed deal value across the ones your studio has an account for.

For each open deal: take the amount in integer cents, take the effective probability in integer basis points — the per-deal override when one is set, otherwise the stage default — multiply, and floor once. Sum those into buckets by owner, stage or close month. Won and lost deals are excluded. A deal with no stage is excluded, because it has no probability basis and the alternative would be to invent one. Nothing is stored, so nothing drifts.

Each stage can carry a rot threshold in days. A deal whose last activity is older than its stage’s threshold is flagged as rotting, and the count rolls up into the forecast bucket. Three rules make the flag trustworthy: a won or lost deal never rots, a stage with no threshold never rots because the studio opted that stage out, and a deal that has never been touched at all is rotting the moment a threshold exists. The never-touched case is the most neglected one, so it gets no free pass.

Yes — the convert verb provisions the school’s own workspace, and the stage-move validator then refuses every subsequent move on that deal. Closed-won here is not a label on a row; it is the moment a customer exists. The immutability is deliberate: a provisioned deal that could be dragged back to “negotiation” is a reporting lie waiting to happen.

No, with one named exception that runs the safe direction. The CRM model carries adult organisation context only — the route module says so in its own header, and no roster or student field is read or written anywhere in it. The exception is the advertiser tear sheet: a student can appear in an advertisement, so before that document is issued the students in the creatives that actually ran are re-checked against publication consent, and one suppressed student blocks the whole document. The only student-facing behaviour in this product is a refusal.

No. A rep reaches its own deals — as the working rep or as the owner — plus the unassigned house pipeline, and nothing else. A deal outside that set comes back as not-found rather than forbidden, so the wall does not confirm the row exists.

No. Support reads across tenants and is refused every write by name: the function that resolves which studio a write targets forbids a support session outright. Reading to help you and writing to your data are different powers and they are separated in code, not in policy.

No. The live payments switch defaults to off, and with it off a live key is held rather than used. So the only settlement this lane can currently record is the honest offline one: a method, a reference, and the staff member the server resolved, written into the audit trail as an offline reconciliation rather than as a provider charge. An invoice in this system never claims a card payment that did not happen.

A registered handler that answers, with tests over its logic, and zero surfaces a user can reach that call it. It is not vapour and it is not a feature. The distinction matters because the characteristic dishonesty of a technical product page is to present a green test suite as a working capability, and this codebase has 9 places where that temptation exists. All 9 are listed by name. The cadence spine is one rung lower still and is described in its own section: it has no handler at all, so it does not even qualify for that table.

Because it is checkable and it argues against itself in the places that matter. Every capability claim on it names the file and, where it is load-bearing, the line. Every count states the instrument that produced it. The comparison table gives the general-CRM category the first four rows outright, including the one where our own coverage is thinnest. And it publishes a correction against our own source: two comments in our web code assert that the deal detail screen is reached from the pipeline cards, and measured at tip that is false — it is a typeable URL. A page that will not contradict its own codebase is not measuring anything.