Field OP — Terms of Service

Version: 0-draft — engineering's draft, written 15 September 2026 for counsel. Status: not in force. Not published, not legal advice, and not a version any customer has been asked to accept. Address: this document is served at /terms and at /terms/0-draft, and its wording is frozen at that address: a correction is the next version, never an edit of this one.

READ THIS FIRST — THIS IS A DRAFT FOR COUNSEL. IT IS NOT LEGAL ADVICE.

This document was written by the engineering side of Field OP so that counsel has something concrete to react to instead of a blank page. It has had no legal review. It is not legal advice and must not be published, shown to a customer, or used to record anybody's acceptance until counsel has replaced it.

What it is good for: every sentence below about what the platform actually does was checked against the code and the schema, not against anybody's intentions. Where the specification describes something the platform does not do, this draft says what is true today rather than what was planned. Where the master handoff marks a question open, this draft leaves it open and says so in place, rather than inventing an answer that would then have to be unpicked.

Two markers appear throughout, and both are for counsel to clear before publication:

• [OPEN — counsel] — a question the Product Owner and the master have deliberately not answered. Governing jurisdiction, the liability cap, the service commitment and pilot terms are the four the master names (§57); a few more surfaced while drafting and are marked the same way.
• [NOT YET BUILT — 15 Sep 2026] — a clause describing a mechanism the launch plan builds but which does not exist as this is written. Every one of these must be true before the terms are published, because publishing a term is a promise. They are marked so that nobody has to take engineering's word for which is which.

Where the master and the code disagree, this draft follows the code, and notes the disagreement. There is one large exception, flagged where it appears: the intelligence clause in section 9 describes the platform as decision 64 of 15 September 2026 sets it, which is on-by-default. The code today is off-by-default. That change lands before launch in the same pull request as the marker rename, and section 9 is written for the platform a customer will actually sign up to.

Source documents: master handoff docs/master/Handoff_Master_v0.5_Part2.md §§56–60 and Appendix A; docs/decisions/2026-09-15-launch.md decisions 59–79; docs/subprocessors.md; docs/legal/Privacy_Notice_Brief.md; docs/plans/2026-09-15-to-launch.md parts B and C.

The four open items the master names, in one place

Counsel should settle these first; the rest of the document is written around them.

1. Who you are contracting with

Field OP is a product of Gestalt Communications Inc., a corporation incorporated federally in Canada ("Gestalt", "we", "us"). Gestalt is the party you contract with, the party that invoices you, and the merchant of record on your card statement. Nobody else stands behind these terms.

"You" and "your organization" mean the campaign, party association, advocacy organization or other body that signs up for Field OP, and every person who uses Field OP under your organization's account.

Locked by master §57: the contracting entity is Gestalt Communications Inc.; Field OP may be described legally as a product of Gestalt Communications Inc.

Assignment and a future spin-out. Gestalt intends, eventually, to move Field OP into a separate company. You agree that Gestalt may assign this agreement, or novate it, to an affiliate or to a successor that acquires the Field OP business, on written notice to you and without your further consent, provided the successor assumes these terms in full. You may not assign this agreement without our written consent, except to a successor organization of your own campaign or association.

[OPEN — counsel] The master requires that a spin-out "will require novation or assignment provisions"; the paragraph above is engineering's attempt at one. Counsel should decide whether notice alone is right, and whether a customer should have any right to object.

2. What these terms cover

These terms govern your use of:

• the Field OP web console;
• the Field OP phone app (Android at launch — see section 10);
• printed walk sheets and paper entry produced by Field OP;
• any documentation, support and services we provide with them.

Together, the "Service".

By creating an organization and paying, you accept these terms on behalf of your organization, and you confirm you are authorized to do so. The version you accepted is recorded, with the exact wording you were shown, and your administrators can read it back at any time.

[NOT YET BUILT — 15 Sep 2026] Self-serve sign-up, the acceptance record (legal_acceptances) and the versioned /terms page are built in part B of the launch plan (stories 0.12.2 and 0.12.3). Today a tenant is created by a staff-run job and there is no acceptance record. The sign-up flow cannot ship without a first version of these terms, which is why this draft exists.

3. Your licence to use Field OP

For as long as your subscription is paid and in good standing, we grant your organization a non-exclusive, non-transferable, revocable right to use the Service for your own political, electoral, advocacy or organizing work, within the limits of the plan you bought.

You may not: resell, sublicense or provide the Service to a third party as a service; copy, decompile or reverse-engineer it; use it to build a competing product; remove or obscure any notice in it; or exceed the plan limits by creating multiple organizations to avoid a cap.

White label and branding. If your plan includes branding options, they apply to what your volunteers and the public see, on the terms we publish for them. Removing or altering Field OP's own attribution where it is required is not permitted.

4. Accounts, users and administrators

Sign-in. Every account signs in with a single-use link sent to a verified email address, or another method we support. There are no shared accounts. An invitation is the only way into an organization — we do not add anybody to your organization except through your administrator's invitation, and neither does anybody else.

Your administrators are responsible for:

• who is invited, what role they hold, and removing people who leave;
• issuing and revoking capability grants, including the Restricted Data grant, which is the only way anybody reads a restricted field or an inferred label;
• the accuracy of what your organization records about people;
• the lawfulness of what your organization does with the Service.

Roles are a closed vocabulary. Your organization cannot invent a permission level. The roles, the ten capability grants and the scope rules are the platform's, and they are enforced in the database, not only in the interface. Some grants are dual-controlled: a second administrator, who is neither the issuer nor the recipient, must approve them, and the database refuses an approver who is either. Restricted Data is one of those.

Dangerous acts need a recent sign-in. Exporting people, changing permissions and signing a destruction certificate each require a re-authentication less than five minutes old. Sessions expire absolutely at twelve hours, whatever you are doing.

Your responsibilities as an account holder. Keep your email account secure — a sign-in link is a key. Tell us promptly if you believe an account has been compromised. You are responsible for what your users do with the Service, including volunteers.

Volunteers. A volunteer is a user of your organization's account, not our customer. You decide what they may see. The platform enforces hard floors on top of your decision — for example, no restricted field and no inferred label ever reaches a phone or a walk sheet, by construction, whatever role you give somebody.

5. Your data, and what belongs to us

5.1 Your data stays yours

You keep your rights in Client Data — the records your organization loads, and everything your organization creates in the Service: people, households, interactions, surveys, tags, custom fields, consent and suppression records, universes, turfs, canvasses and the rest.

This is subject to three things that are not ours to waive: the rights of the individuals the data describes; the restrictions attached to the source it came from (a voters' list carries its own rules — section 8); and the limited licence you give us below so that we can actually run the Service for you.

5.2 The licence you give us

You grant us a limited, non-exclusive licence to host, copy, transmit, display and process Client Data only in order to:

• deliver, secure and support the Service;
• perform integrations you have asked for;
• comply with law and with this agreement;
• generate the telemetry described in our privacy notice;
• create de-identified aggregate operational benchmarks under the safeguards in §5.4;
• train a per-tenant model for your organization's own use.

Nothing else. In particular:

• We do not sell Client Data, and we do not sell or share voter or contact data.
• We do not train general third-party models on your content. No content of yours is sent to a general-purpose AI provider for training.
• There is no automatic flow of your data to Gestalt's other products.
• We do no cross-site tracking, device or cookie identity linkage, or commercial data enrichment.

5.3 What belongs to Gestalt

We own the Field OP software, its design, its generic workflows, its documentation, its security architecture, its orchestration systems, and generic improvements to the product — including improvements we make after seeing how the Service is used in general.

Models, said precisely, because the line matters. A per-tenant model trained on your data is associated with your organization: we do not transfer it, reuse it for another customer, or sell it, and at closeout it is destroyed or exported to you. The modelling method, the features, the pipelines, and platform-level models built on de-identified aggregates or licensed data are ours. The name-based labelling model described in section 9 is a platform-level model of ours; the labels it writes about your people are Client Data.

5.4 Benchmarking

Your raw data stays bound to your organization. We may turn approved metrics into de-identified aggregate benchmarks under defined cohort rules. We do not benchmark candidate support, opposition, individual characteristics or your strategy.

[OPEN — counsel] The master (§58.3) lists as still to define: the exact de-identification standard, customer opt-out rights, the processing licence, export rights, per-tenant model treatment at closeout, and the treatment of proprietary model improvement. At least a launch subset of these needs settling, and some of it may belong in separate data-processing terms rather than here (see §17.4).

5.5 Pooled calibration counts — a cross-organization read, named

One thing does cross the boundary between organizations, and it is better named here than discovered. When the labelling model in section 9 guesses something and a person then tells one of your volunteers the answer, the pair — what the model said, what the person said — is counted. These counts are integers. They carry no person, no name, no record identifier, and once pooled, no organization identifier. By default they are pooled across every organization on the platform, so that the model's accuracy figures mean something.

Your administrator can switch pooling off, and then your organization learns only from its own counts. Your administrator also chooses, in advance, whether your counts stay in the pool or are deleted if your organization is deleted.

[OPEN — counsel] The privacy brief asks counsel directly whether a pooled aggregate of this shape is a processing of personal information at all, and whether a deleted organization's counts remaining in the pool raises anything under retention obligations. The answer changes what this clause has to say. The relevant Review Gate (H08, cross-tenant sharing) is on Hold.

6. Acceptable use

You will use the Service lawfully. In particular you will not use it for:

• violations of election law or privacy law;
• voter intimidation or suppression;
• false polling or false voting instructions;
• impersonation, fraud, threats or harassment;
• illegal spam, unlawful automated calling, or contacting people who are suppressed;
• uploading data you do not have the right to upload;
• scraping, probing other organizations' data, or trying to bypass permissions;
• unauthorized resale of data;
• malware or disrupting the Service;
• fraudulent fundraising;
• using AI features to get around a compliance or security control.

Intelligence-specific prohibitions. You will not:

• use an inferred trait to exclude, discourage or suppress contact with a group — inferred traits exist to match volunteers to turfs and to choose the language material is offered in, and for nothing else;
• present a model score to any person as a statement of fact about them;
• try to re-identify individuals from aggregate or benchmark data;
• use message testing to deliver false or unapproved claims, or to vary a required disclaimer;
• get around a suppression, a quiet-hours rule or a consent record by any means, including by asking an AI feature to do it;
• upload data intended to poison or manipulate a model.

Our posture. Field OP is politically neutral infrastructure, not an editorial publisher. We do not approve or reject political viewpoints, and we serve campaigns across the spectrum. We do enforce lawfulness, platform safety and the rules above, and we keep commercial discretion to decline or end service where there is material legal, security, sanctions, conflict-of-interest or reputational risk.

Enforcement is a ladder: a warning or a request to correct something; then a feature restriction or a pause; then suspension of a user or of your organization; then termination. We preserve evidence and report where the law requires it. You may appeal a substantive enforcement decision, and we will tell you how when we act.

[OPEN — counsel] Master §59 is written as a standalone Acceptable Use Policy, and the launch plan gives it its own page accepted at sign-up. Counsel should decide whether this section stays here in full, or shrinks to an incorporation by reference. The order of precedence in §17.4 assumes the AUP is a separate document.

7. Election-law compliance — what we do and what we do not do

Field OP is not your lawyer and is not automated legal counsel. Compliance features are aids. They do not make your campaign compliant, and a feature that lets you do something is not advice that you may lawfully do it.

What the Service actually does:

• Hard controls you cannot override: permission and organization boundaries, suppression and do-not-knock, expired missions, restricted-field access rules, and destruction controls.
• Controlled blocks an authorized administrator may override with a permission, a reason and an audit record, where that is legally appropriate.
• Warnings you acknowledge and proceed past, with the acknowledgement recorded.

[CORRECTED 15 September 2026 — engineering, on moving this draft into the repository] The first bullet named quiet hours as a hard control, following the master's §60 control taxonomy. Nothing in the platform enforces a time window on contact. There is no column, no constant, no check, no jurisdiction pack that carries one, and no code anywhere that reads an hour of the day. Publishing a term is a promise, so the words came out rather than the sentence being softened. The prohibition on circumventing quiet hours stays in §6 and in the acceptable-use policy, where it binds a customer without claiming a control. docs/legal/Findings.md, finding 3.

Compliance is configuration. A jurisdiction pack carries identity and sponsor requirements, communication rules, voters'-list access and destruction rules, retention obligations and required acknowledgements. Ontario municipal rules are the pack that exists at launch.

You are responsible for choosing the right jurisdiction configuration, for registering where registration is required, for the content of what you send and say, and for the lawfulness of your contact, targeting and messaging.

[OPEN — counsel] Québec. There is no jurisdiction gate at launch. A Québec organization can sign up self-serve, and Law 25's automated-decision provisions and CAI notice duties are raised in the privacy brief and unanswered. The mitigation in the plan is narrow and specific: the province is captured at sign-up and a Québec organization starts with labelling switched off. Counsel should decide whether these terms need to say more than that — for instance whether a Québec organization can lawfully be sold this product self-serve at all before the compliance model exists. [NOT YET BUILT — 15 Sep 2026] for the province capture and the Québec default.

8. Voters' lists: restricted handling and your destruction obligations

This section is the one most likely to be read by a returning officer, so it is written plainly.

A voters' list is not ordinary data and the Service treats it differently. When you import one:

• you classify the source and record its retention rule and its destruction date;
• you sign a custody acknowledgement naming both, and that acknowledgement is kept permanently and cannot be edited or deleted;
• every copy taken from that source afterwards — every export, every printed walk sheet, every mission bundle sent to a phone — is recorded in a copies register with who received it, so you can count what is outstanding at any moment;
• restricted fields (date of birth, sex or gender) are held apart behind the Restricted Data grant and never reach a phone or a walk sheet;
• exports of people require a re-authentication within the last five minutes, and an exported file is fetchable once and expires after 24 hours — the record of the export outlives the file;
• a mission bundle on a volunteer's phone expires at the end of the canvass window or in 24 hours, whichever comes first, and the phone purges it 12 hours after that.

Your obligations, which we cannot discharge for you. You must comply with every restriction attached to the list by the authority that issued it: the permitted purposes, the limits on who may hold a copy, the retention rule, and the destruction deadline. You must destroy the list and its copies when required, and you must collect whatever confirmations the issuing authority requires from everyone who held a copy — including your volunteers' phones and every sheet of paper.

The honest limit, which must survive counsel's redraft

Field OP does not carry out destruction, and a destruction certificate from Field OP is not evidence that anything was destroyed. The platform records the undertaking, tracks every copy and derivative, and can produce a certificate stating what was outstanding and who held it at a given moment. The certificate says so on its face. Actually destroying copies, and collecting each holder's written confirmation, is your job and a later release of ours.

Related and equally honest: records in the Service are soft-deleted. Hard deletion is revoked at the database for the application, deliberately, so that an application bug cannot erase evidence. Custody acknowledgements, destruction certificates and the audit trail are append-only and cannot be erased at all, because they are the accountability the rest of this section depends on.

[OPEN — counsel] This is a real gap between what a returning officer may expect and what the platform can do, and it is the sharpest thing in this section. Counsel should decide how it is stated to a customer and whether it needs a positive undertaking from the customer in return.

9. Intelligence: name-based labelling, AI limits, and your responsibility

This section is load-bearing. Your organization's acceptance of the labelling terms is recorded against a version string in tenant_inference_settings.terms_version, and a label the platform writes can be resolved back to the exact words the person who authorized it was shown. If a word changes here, the version changes. Counsel must treat the wording of this section and of the in-product labelling terms as one document in two places, and they must not drift apart.

9.1 What the feature is

Field OP includes a model that reads a person's family name and records what it guesses about their language, ethnic community or religion. It is a guess from a name and nothing else — not from anything the person told you, and not from anything they did.

9.2 On by default, and you can switch it off

Labelling is on for a new organization by default, as a matter of Field OP's platform policy, decided by the Product Owner on 15 September 2026. Your organization's settings row records that the platform's default enabled it, not that one of your people clicked a button.

A tenant administrator may switch it off at any time, and labels stop being produced immediately. Turning it off and on again records that somebody agreed to the terms then in force. Labels already written stay on record, so that the decision can be audited and anything acted on can be found; they can be deleted, but only as a deliberate act.

[OPEN — counsel] Which characteristics are computed by default has not been decided. One design review recommends language, ethnic community and residency stability on with religion off; another recommends language alone, with the rest opt-in. It is a Product Owner decision before the migration is written, and these terms must name whichever set is chosen.

[NOT YET BUILT — 15 Sep 2026] The code today is off by default. The default change, the new marker in §9.5 and the second version of the in-product labelling terms land together in one pull request, and ADR-038 records the reversal of ADR-037, so that no label ever carries a marker that lies.

9.3 The written legal opinion has not been filed

A written legal opinion on this feature has been requested and has not yet been filed. Counsel's approval of name inference was reported verbally on 12 September 2026; the document has never arrived. There is also no privacy impact assessment, no model card and no bias evaluation on real data. The Product Owner's decision is that launch proceeds anyway and those gates follow.

Field OP does not represent that this feature is lawful in your jurisdiction, and you should take your own advice before relying on it. The administrator screen in the product says the same thing, in amber, citing the same decision.

[OPEN — counsel] How much of the paragraph above belongs in customer-facing terms is a judgement for counsel. Engineering's position, recorded once: the marker in §9.5 is written on every label precisely so this is not a private fact, and a term that said less than the label says would be strange.

9.4 What a label is never allowed to be

• A guess is never recorded as a fact. A label is stored apart from the person's record, marked as inferred, with the model, the model version, the evidence, the explanation and a date it stops being current. It is never written into a name field, a language field or anything else your organization holds as a fact.
• A trait a person states about themselves outranks the model's guess, always. If somebody tells your volunteer their language, that is what your organization holds; the guess does not overrule it and does not come back.
• No message is ever selected from an inferred trait. The platform has no mechanism that chooses what to say to somebody on the basis of a guess about their community or religion.
• A human can confirm, correct, reject or switch off any label, for any individual, and a label a human rejected is not produced again by the same version of the model. Low-confidence guesses are stored and never shown.
• Who can never see a label: no volunteer, no team captain, no candidate — not on a screen, not on a phone, not in an export, not on a printed walk sheet. Reading a label requires the Restricted Data grant, which is dual-controlled, expiring and separate from any role. This is enforced in the database, so it holds for software written later.

9.5 The marker on every label

Every label written while the opinion is outstanding carries the marker legal_opinion_pending: computed under the platform's default policy, with a written legal opinion requested and not yet filed. When the opinion is filed, new labels carry a dated marker instead, these terms move to their next version, and the amber notice goes.

[NOT YET BUILT — 15 Sep 2026] Labels written before the change carry the earlier marker not_for_a_real_campaign_before_a_legal_opinion, because the table is append-only. That marker would be a lie the first day a real campaign is labelled under it, which is why the rename and the default change ship together.

9.6 How wrong it is

It is wrong often, and unevenly. On the synthetic test population the model is right about roughly 88% of names from one community and 62% from another — twenty-six points apart, where a single average would report seventy-eight percent and conceal both ends. The accuracy report is ordered worst-community-first for that reason, and your administrators can see it before and after switching the feature on.

Religion is the weakest of the three. A name can suggest a community. It cannot tell you what somebody believes, or whether they believe anything. Field OP produces a religion label by applying a published assumption about a community to a person, and usually declines to name one answer and shows a spread instead. Treat it as the least reliable thing the platform will ever show you.

A name is weakest evidence precisely for the people most often misunderstood — adoptees, converts, people who married across a community, and families longest in the country.

On a real campaign the accuracy report cannot break down by community at all, because nobody knows anybody's actual community. Only a person's own correction can measure it, one at a time, after the fact.

9.7 Nothing is sent anywhere

The model runs inside Field OP on Canadian infrastructure. No name, and nothing else about any person, is sent to a third-party name-classification service, to a demographic-inference API, or to a general-purpose AI provider, for this feature or any part of it. A hosted backend for this classifier was written and then removed for exactly this reason.

9.8 Human review, and your responsibility for what you decide

This applies to every AI feature in the Service, not only labelling.

• AI output is a suggestion, and a human confirms it. Import column mapping is proposed by a model and accepted, edited or rejected by a person, and the outcome is recorded. Anything a model produces about a person is an estimate.
• You are responsible for your targeting and messaging decisions, including decisions you make using model output. If you choose who to contact, what language to offer, or what to say on the basis of something Field OP inferred, that is your decision and your organization's responsibility, and you are responsible for it being lawful and non-discriminatory.
• You will use labels only for lawful, non-discriminatory purposes connected to your stated work — offering material in a language somebody is likely to read is the example the product gives. You will not use them to exclude anyone from contact, to target anyone on the basis of religion, or for any purpose that would be unlawful if the person had told you the same thing directly.
• If a person asks what your organization believes about them and why, that answer is yours to give. The platform can produce it — the label, its confidence, the model version, and the fact that it came from their name — and there is no self-service route for a member of the public. They come to you.

10. The phone app is Android only at launch

The Field OP phone app runs on Android at launch. There is no iPhone app.

This is a straightforward consequence of what is built: iOS needs a cloud build, an Apple Developer Program membership and App Store review, none of which is started. It is not a statement about which phones your volunteers ought to own.

A volunteer without an Android phone is not turned away. They canvass from a printed walk sheet, and the results are entered in the console through paper entry. Both are built, both work, and both go through the same custody and copies register as a phone bundle does — a walk sheet is a copy of people's data on paper and is tracked as one. Your volunteer onboarding material says this rather than leaving anybody to discover it.

We may add an iOS app later. Nothing in these terms commits us to a date.

11. Third-party services

The services Field OP itself uses are listed in our privacy notice and in our sub-processor register, which is the authoritative list. Four of them process data outside Canada, and all four are disclosed by name:

None of these carries voter data. Everything else the platform runs on is in Canada. Canadian data residency for the rest of the platform is a standing constraint that the Product Owner has consciously set aside for these four exceptions through launch, and each is recorded.

We will give you notice before adding a new sub-processor.

[OPEN — counsel] The notice mechanism the plan proposes is the sub-processor page plus thirty days' email. Counsel should set the period and decide whether you get a right to object, and what happens if you do. [NOT YET BUILT — 15 Sep 2026] for the notice mechanism, the Stripe register row and the Workspace relay row.

Integrations you enable. If we later offer integrations with services you choose, you are responsible for your relationship with that service, for what you authorize it to read or write, and for its terms. We are not responsible for a third-party service's availability or for what it does with data you direct us to send it. There are no customer-enabled third-party integrations in the Service today, and a public API is not part of this launch.

12. Fees, payment and taxes

A card at sign-up. Field OP is paid software. There is no free tier and no invoicing at sign-up: you give a card when you create your organization, and the subscription starts immediately.

How payment works. Payment is taken through Stripe. You are sent to Stripe's own hosted page to enter your card. Card details never reach Field OP — we keep Stripe's identifiers and a card fingerprint used to spot abuse, and nothing else. Stripe's own terms apply to your payment relationship with them; the merchant of record, and the name on your invoice, is Gestalt Communications Inc.

Plans and billing period. Plans are annual subscriptions and renew automatically unless cancelled. You can change plan, update your card and read your invoices through the billing screen and Stripe's customer portal. A campaign that has finished can downgrade to the between-cycle rate, which keeps your organization and its records alive between elections.

Taxes. Prices exclude tax. GST, HST, QST and provincial sales tax are calculated and added at checkout based on where you are. You are responsible for any tax registration of your own.

Plan limits. Your plan includes limits — contacts, active campaigns, support tier. Limits bind bulk operations and the creation of new things: a new campaign, an un-archive, an import. A limit never refuses a single record at a door or a stall. A resident standing in front of a volunteer is always recorded.

If a payment fails, we will tell you and retry. After a grace period your organization moves to read-only: you can read, export and fix your billing, and you cannot write. Paying restores you.

We do not process political donations. Field OP bills your organization for software. It has no fundraising module and does not handle contributions.

[OPEN — counsel] Refunds and cancellation: is a mid-term cancellation refundable, pro-rated, or neither? Nothing in the repository decides this. Also: notice period for a price change at renewal; whether the grace period before read-only is stated in these terms (the plan's recommendation is seven days, not yet decided) and whether it should be.

[NOT YET BUILT — 15 Sep 2026] The whole of billing is part B of the launch plan: sign-up, Checkout, the webhook, the billing screen, dunning and limits. Stripe Tax computes the taxes above once Gestalt's tax registrations are entered, which has not been done.

13. Suspension, termination and closeout

You may cancel at any time, effective at the end of your current term, through the billing screen.

We may suspend or terminate for non-payment, for a breach of section 6, where the law requires it, or where continuing to serve you would create material legal, security or sanctions risk. Except where the situation is urgent or the law forbids it, we will tell you first and give you a chance to fix it.

What suspension actually means, because it is modelled rather than improvised:

• Read-only — you can read, export and manage billing. You cannot write. This is where a failed payment lands you, and the reason read-only still allows export is that your data is yours and you must be able to take it out.
• Suspended — billing only. Nothing else.

Suspension for cause is a decision a person takes with a reason recorded; it never happens automatically.

At closeout. When your subscription ends, you may export your Client Data for a period after termination, after which we delete or de-identify it. Your obligations under section 8 — the voters' list, its copies and its destruction deadline — do not end when your subscription does. Records that are append-only evidence, including the audit trail, custody acknowledgements and destruction certificates, are retained.

[OPEN — counsel] Four things here need numbers or positions nobody has set: how long after termination you can export; what we then do with the data and when; what happens to a per-tenant model at closeout (the master requires this be explicit in the contract and it is on the still-to-define list); and whether a suspended organization can still export. Engineering's recommendation on the last is yes — read-only and suspended differ deliberately, and a campaign that cannot pay is still entitled to its own records.

14. Confidentiality and security

Confidentiality. Each of us will keep the other's confidential information in confidence and use it only for this agreement. Your Client Data is your confidential information. Our non-public documentation, pricing and security architecture are ours. Neither of us needs to keep confidential what is public, already known, independently developed, or required to be disclosed by law — with notice to the other where notice is lawful.

What we do. Stated conservatively, and each of these is enforced and tested:

• Organizations are isolated at the database. Row-level security means an application bug cannot read across organizations, because the database refuses — not because the code remembers to check.
• Roles are a closed vocabulary, and restricted classes need a separate, expiring, dual- controlled grant on top of a role.
• A phone never holds restricted data, by construction. A bundle carrying a forbidden field is refused and discarded by the app itself.
• Mission bundles are signed, and the app opens only bundles whose signature checks out.
• The audit trail is comprehensive, immutable, and cannot be used to read personal data. Every event records which record changed, by whom, and the shape of the change — identifiers, counts, timestamps, statuses and hashes — and never the content. Not a name, not a contact detail, not what somebody said at a door. This is checked in our build over every audit payload in the system and fails the build on any key that is content.
• Sessions expire absolutely at twelve hours; dangerous acts need a re-authentication within five minutes.
• Encryption in transit and at rest.

What we do not claim. We hold no SOC 2 or equivalent attestation. Do not read this section as one.

[OPEN — counsel] Three items must be checked against reality on the day these terms are published, because they are moving: a penetration test (scheduled in the launch plan, not yet performed as this is written); a written breach notification procedure (a skeleton is planned, not written); and Gestalt staff access to your organization. On the last: the master's position is that Platform Owner access is logged and visible to the client. Today Gestalt has no audited way to enter a customer's organization at all; the launch plan builds one as a real, time-boxed membership that appears in your own access log. Until it exists, neither the master's promise nor a denial of staff access can be stated. [NOT YET BUILT — 15 Sep 2026]

What you do. Keep your users' email accounts secure. Review your administrators and grants. Do not share accounts. Tell us promptly about a suspected compromise. Do not put data in the Service that you have no right to hold.

15. Pilot, beta and early-access features

[OPEN — counsel] Master §57 marks pilot terms open, and they remain open.

What engineering can tell counsel: there is no pilot programme. The master planned an internal alpha, a controlled field test and a by-election pilot in mid-2027; decision 60 of 15 September 2026 compressed all three into one launch open to any campaign that signs up and pays. So there is no cohort of pilot customers to write terms for, and the clause counsel may actually need is a beta-feature clause: a feature marked beta is provided as-is, may change or be withdrawn, and is outside whatever service commitment §16.1 ends up carrying.

If a design partner arrangement is signed later — for instance one whose contract requires Canadian residency, which is one of the things that would reverse decision 61 — it will need its own terms, and those should be a separate agreement rather than a clause here.

16. Availability, disclaimers, liability and indemnity

16.1 Availability

[OPEN — counsel] The service commitment is one of the master's four open items.

What is true today: there is no published SLA, and the launch recommendation is not to publish one at launch. Support is one tier, business hours Eastern, with a first response targeted within one business day. Availability is monitored continuously. We hold internal recovery objectives — a five-minute recovery point and a two-hour recovery time, one hour in an election-critical period — and those are engineering objectives, not promises to a customer, and must not become promises by being written down here.

The master describes three support tiers, including extended coverage during an active campaign and an election-critical tier. Those tiers do not exist at launch. Counsel should not describe them.

Election-critical periods and change freezes. We operate a change freeze around voting days and advance voting. During a freeze we ship only data-integrity fixes, with two-person approval.

Maintenance and changes. We may change, add to or remove features. We will not make a change that materially reduces the Service's core function without telling you. We may update these terms; see §17.3.

16.2 Disclaimers

The Service is provided as it is. To the extent the law allows, we disclaim implied warranties of merchantability, fitness for a particular purpose and non-infringement.

We specifically do not warrant that:

• the Service makes you compliant with election or privacy law. It enforces rules and raises warnings; it is not legal advice and it is not a lawyer;
• any inference, score or model output is accurate. Section 9 says in numbers how wrong the labelling model is, and those numbers are measured on synthetic data that was built to be classifiable — a real population is read less accurately, not more;
• the Service destroys data on a schedule. It records who holds what and refuses to imply more (section 8);
• third-party services we depend on will be available.

16.3 Liability

[OPEN — counsel] The liability cap is one of the master's four open items, and no number has ever been discussed in the repository. The shape counsel will probably want: a cap tied to fees paid in the preceding twelve months; exclusion of indirect and consequential loss; and carve-outs from the cap for the things a cap should not cover — engineering's list, offered as a starting point rather than a position, is a party's own wilful misconduct, a breach of confidentiality, an indemnity under §16.4, and unpaid fees.

Worth counsel's attention when setting the number: the realistic worst case here is not a refund claim. It is cross-organization exposure of a voters' list, or an inferred religion label reaching somebody it must never reach. Both are treated as release-blocking defects internally.

16.4 Indemnity

You indemnify us against claims arising from: data you loaded that you had no right to load; your use of the Service in breach of section 6 or section 7; your contact, targeting and messaging decisions, including decisions made using model output; and your handling or non-destruction of a voters' list.

We indemnify you against a third-party claim that the Service itself infringes an intellectual property right, other than where the claim arises from your data or your use of the Service in breach of these terms.

[OPEN — counsel] The scope of both, the procedure (notice, control of defence, settlement), and whether the IP indemnity carries the usual repair-replace-refund remedies.

17. Governing law, notices, changes and precedence

17.1 Governing law and jurisdiction

[OPEN — counsel] One of the master's four open items.

The launch plan's own recommendation is Ontario, and counsel should weigh: Gestalt is federally incorporated; the first jurisdiction pack and the first customers are Ontario municipal; and the product is sold across Canada, including Québec, whose consumer and privacy regimes may not accept an Ontario choice of law for every customer.

17.2 Notices

We give notice to your administrators at the email addresses on your account, and by a notice in the console. You give notice to us at the address we publish for legal notices. A notice by email is effective when sent.

[OPEN — counsel] The address for legal notices needs to exist and be named. support@fieldop.ca is the planned support address and is not the same thing.

17.3 Changes to these terms

We may update these terms. Each version is published at its own address and never edited: a change is a new version. Where a change is material we will tell your administrators and ask them to accept the new version; where it is not, we will publish it and note the date.

[NOT YET BUILT — 15 Sep 2026] Re-acceptance of a later version by existing customers is its own story in the launch plan, sequenced after counsel's text arrives. The versioned pages and the acceptance record at sign-up come first.

17.4 Order of precedence

If these documents conflict, the order is:

1. a signed written agreement between us (an enterprise or design-partner agreement);
2. the data-processing terms;
3. these Terms of Service;
4. the Acceptable Use Policy;
5. the Privacy Notice;
6. product documentation and in-product terms, including the in-product labelling terms of section 9.

[OPEN — counsel] This ordering is engineering's proposal, not a decision. Two points worth counsel's eye. The in-product labelling terms sit at the bottom of this list but carry the version string that a tenant's acceptance is recorded against, and they are more specific than section 9 — counsel should decide whether the specific wins over the general there, or whether section 9 and the in-product terms should simply be the same text rendered twice. And the privacy notice may need to sit above these terms rather than below, depending on the controller/processor answer the privacy brief asks for and nobody has yet given.

Appendix — where the facts in this draft come from

For counsel's verification. Every operational claim above traces to one of these.

End of draft. Nothing in this document has been reviewed by a lawyer.