What a campaign may and may not do with the platform, and what happens when it does not.

Field OP Acceptable Use Policy

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 /acceptable-use and at /acceptable-use/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: what this document is
This is a draft for counsel. It is not legal advice, and it is not in force. It was written by engineering from the master specification (§59), the launch decision record (decisions 59 to 79) and the code, so that counsel has something concrete to react to rather than a blank page.
Two things it is built to be good at, and one it is not. It is accurate: every statement below about what the platform actually does was checked against the schema and the source, and where the specification describes an intention nobody has built yet, this draft says so rather than promising it. It is complete on the product side: the prohibited uses are the master's, carried whole. What it is not is settled law — the wording, the enforceability, the notice periods, the appeal mechanics and every item marked [OPEN] are counsel's to settle, and counsel's text replaces this document rather than amending it.
Marked gaps. [OPEN] means the master or the launch decisions leave the point open and this draft does not invent an answer. [ENGINEERING NOTE] means a statement about the platform that is true today with a qualification, or that depends on a specific piece of work landing before this policy is published. Both markers come out of counsel's version.

1. What this policy is

This policy sets out what you may and may not do with Field OP. It applies to the organization that holds the account, to everyone the organization gives access to — administrators, managers, organizers, candidates and volunteers — and to anyone acting on the organization's behalf.

Field OP is a product of Gestalt Communications Inc., a federally incorporated Canadian company. Gestalt Communications Inc. is the contracting party. In this policy "we" and "us" mean Gestalt Communications Inc., and "you" means the organization that holds the account.

This policy sits alongside the terms of service, the privacy notice and the data processing terms. Where they conflict, [OPEN — order of precedence: the master's §57 lists it as a term to be settled; counsel to state which document wins].

2. Our position: neutral infrastructure, not an editorial publisher

Field OP is politically neutral technology infrastructure. We do not approve or reject political viewpoints, and we do not decide who deserves to organize. What we enforce is the law, the safety of the platform, and the abuse rules set out in this policy.

This is deliberate, and it is worth being plain about it. Some campaign platforms will serve only one side of the political spectrum. Field OP serves nonpartisan municipal politics and campaigns and advocacy organizations across the spectrum, subject to law and to this policy. A campaign is not refused service here because of what it believes.

What we do keep is commercial discretion. We may decline to provide service, or end it, where there is material legal, security, sanctions, conflict-of-interest or reputational risk. That is a business judgment about a relationship, not an editorial judgment about a viewpoint, and the two are kept separate on purpose — see section 7.

3. Sign-up is self-serve, so review happens after you start

Anyone can create an organization on Field OP from a public page and start immediately. There is no waiting list, no approval step and nobody from Gestalt in the path.

That has a consequence worth stating plainly rather than leaving you to discover it: because we do not check you before you start, we review after you have started. Shortly after an organization is created we carry out an acceptable-use and commercial-conflict review. In almost every case you will never hear about it. Where it finds a problem, the outcome is a conversation, and in the rare case that the problem is serious, a restriction or a suspension of an account that already exists — not a refusal to let you open one.

In practical terms: starting to use Field OP is not our approval of what you intend to do with it. The rules in this policy bind you from your first day, and the enforcement ladder in section 6 is how they are applied.

[OPEN] — how long after sign-up the review is completed, whether you are told when it has been completed without a finding, and what notice you get before a restriction takes effect.

4. Prohibited uses

You may not use Field OP, and you may not permit anyone using your account to use it, for any of the following.

4.1 Law, elections and people

Violating election law or privacy law, in any jurisdiction where you operate.
Voter intimidation or suppression of any kind.
False polling or false voting instructions — wrong dates, wrong locations, wrong eligibility rules, or anything else designed to stop somebody voting or to send them to the wrong place.
Impersonation, fraud, threats or harassment, whether aimed at a member of the public, at a volunteer, at an opponent or at anybody else.
Illegal spam, unlawful automated calling, or contacting people who are suppressed. A do-not-contact instruction is not a preference to be worked around.
Uploading data you do not have the rights to use, including any list obtained in breach of the terms it came under. Voters' lists obtained under electoral legislation carry their own access, use and destruction obligations, and those obligations follow the data into Field OP.
Unauthorized resale or redistribution of data held in the platform.

4.2 The platform itself

Scraping, probing other tenants, or attempting to bypass permissions. Every campaign's data is isolated at the database, not merely hidden in the interface; attempting to get around that is a serious breach of this policy whether or not it succeeds.
Malware, or anything that disrupts or degrades the service for us or for another customer.
Fraudulent fundraising. Field OP does not process donations, and it may not be used to solicit them fraudulently through any channel.
Using AI — ours or your own — to get around a compliance or security control. If a control would refuse a person, it refuses the same request made through a model.

4.3 Intelligence-specific prohibitions

These matter more than the rest, and they are stated without softening. Field OP can produce estimates about people — including labels inferred from a family name — and the rules below are what keep that capability from becoming something else.

You may not use an inferred trait to exclude, discourage or suppress contact with a group. Inferred traits exist to match volunteers to the people they can talk with and to choose the language a piece of material is written in. Using them to decide who does not get knocked on, who does not get a reminder, or who is worth less effort is prohibited, and it is the single use this platform was built to refuse.
You may not present a model score or an inferred label to any person as a statement of fact about them. These are estimates. They are wrong often, and they are wrong unevenly — the error falls hardest on adoptees, on converts, on people who married across a group, and on families longest in the country.
You may not attempt to re-identify individuals from aggregate or benchmark data, including the pooled calibration counts described in the privacy notice.
You may not use message testing to deliver false or unapproved claims, or to vary a required disclaimer. Testing which of two approved wordings works better is the feature. Testing whether you can get away with dropping a sponsor identification is not.
You may not circumvent suppression, quiet hours or consent by any means, including by asking an AI feature to do it for you. "Any means" is meant literally: a second list, an export, a different channel, a volunteer's personal phone, or a prompt.
You may not upload data intended to poison or manipulate the platform's models, including fabricated survey answers or corrections submitted to move a model rather than to record what somebody said.

5. What the platform enforces, and what is on you

We think you should know which of these rules the software will refuse to let you break and which depend on you. A rule the platform enforces is still your obligation; a rule it does not enforce is not a smaller obligation.

Enforced by the platform today:

Tenant isolation. The database refuses cross-campaign reads. An application bug cannot expose another customer's data.
Who may read an inferred label. Reading a trait requires the Restricted Data grant, which is time-boxed and dual-controlled — the database itself refuses a grant approved by the person who requested it or by the person who receives it. Frontline roles, including every volunteer, are refused traits and restricted fields outright, and traits are never exportable.
Traits never reach a phone, and they cannot be used to choose which wording a volunteer is asked to say. The wording rules a canvass can use are limited by construction to fields the mission bundle already carries plus the person's stated language; an inferred trait cannot be one of them.
A stated fact outranks a guess. When somebody tells a volunteer their language at a door, that statement is recorded as a first-party assertion, supersedes the previous one, and is the heaviest signal the model reads. It never disappears: the second, third and tenth statements are all kept.
Labels are superseded, never overwritten, and every label carries its model, its version, its evidence, its confidence and its usage restrictions on the row.
Suppression is recorded per person, propagates to the household, and reaches the phone.
An immutable audit trail records which record changed, by whom, and the shape of the change — and never the content. A check in the build refuses any new audit payload that would carry content.

[ENGINEERING NOTE] Two things in this section are worth counsel knowing precisely. First, quiet hours and calling windows are specified but not built, because telephony is not part of the launch — the prohibition in section 4.3 binds you regardless, and it is not backed by a control today. Second, required disclaimers and sponsor identification are your responsibility; the platform carries the fields but does not verify that what you send is compliant.

On you, and not enforceable by software:

That your list was lawfully obtained and is lawfully used.
That what you say at a door, on a call or in a message is true.
That the people you give access to understand these rules. Volunteers see real people's information on their own phones.
Decisions made using model output are yours. Field OP is not automated legal counsel and it is not a decision-maker. A human reviews, and a human is responsible.

6. Enforcement

Where we find a breach of this policy, we act in steps, and we start at the lowest one that fits.

A warning, or a request that you correct something. Most matters end here.
A feature restriction, or pausing a specific activity — for example, turning off a capability that is being misused while the rest of the account carries on working.
Suspension of a user or of the whole organization.
Termination.

We may move directly to a higher step where the breach is serious, where somebody is at risk, or where the law requires it.

What suspension means for your data. Suspension is a change to your organization's standing, not a deletion. Nothing is erased. Where an account is put into read-only standing, reading and export stay available so that you can take your own data out, and billing stays available so that you can put the account right.

[ENGINEERING NOTE] The graduated standing described in the paragraph above — suspended meaning billing only, read-only meaning read, export and billing — lands in story 0.12.6 and must be in production before this policy is published. Today a suspended organization cannot sign in at all: the sign-in path already refuses a tenant whose status is suspended, which is the correct refusal but a blunter one than this paragraph describes. An individual's access is ended by removing their membership and revoking their sessions; there is no separate per-user suspended flag.

Evidence. Where a matter involves unlawful conduct or a risk to somebody's safety, we preserve the relevant records and report where we are legally required to. [OPEN — what we preserve, for how long, and the standard for reporting to an authority without a legal order. This interacts with the immutable audit trail, which cannot be deleted at all.]

Appeal. You may appeal any substantive enforcement decision, and a person who was not involved in the original decision reviews it. [OPEN — where an appeal is sent, who decides it, how long it takes, and whether a restriction stays in force while an appeal is pending. There is no appeal route built into the product today; at launch this is a mailbox and a person.]

7. Commercial conflict review

Separately from this policy, Gestalt may carry out an internal commercial conflict review where a prospective customer's work could materially affect an existing Gestalt relationship. That is business governance. It is not product editorial policy, and it is not a political test.

This review must never become a way for one customer to learn that another is a customer. It is carried out without disclosing tenant identities beyond the people who need to know, and the outcome told to anybody outside that group is a decision, never a reason that names somebody else. We will not confirm or deny that any organization uses Field OP.

8. Reporting misuse, and changes to this policy

If you believe somebody is misusing Field OP — including somebody inside your own organization — tell us. [OPEN — the address. support@fieldop.ca and privacy@fieldop.ca are being created; a policy published before they exist would point nowhere.]

This policy is versioned. A new version is published as a new version rather than an edit to this one, so that it is always possible to say which words you agreed to and when. [OPEN — whether a material change requires re-acceptance before continued use, and how much notice is given.]

9. What this policy does not settle

Listed here so that nothing below is mistaken for a position we have taken.

[OPEN] Governing law and jurisdiction. The master leaves it open; Ontario is the internal recommendation and not a decision.
[OPEN] Liability cap, service commitment and pilot or beta terms — all open in the master's §57. There is no published availability commitment at launch, and this policy must not imply one.
[OPEN] Whether this document is a standalone policy incorporated into the terms, or a schedule to them.
[OPEN] Whether a customer must positively accept this policy at sign-up, or is bound by accepting the terms that incorporate it.
[OPEN] Whether the intelligence prohibitions in §4.3 need their own acknowledgement, separately from the versioned labelling terms a tenant administrator already agrees to in-product.

Appendix A — the inference feature, stated exactly

This is the sharpest thing in these documents and counsel should have it in one place, unrounded.

Name-based trait inference is ON BY DEFAULT for a new organization, with a tenant toggle to turn it off. That was the Product Owner's decision of 15 September 2026 (decision 64), recorded as overriding the master's §41.4, which had required a current model card, reported cohort quality, an attached bias evaluation, a Review Gate record and PIA coverage before any trait inference ran.

Counsel's written opinion on name-based inference has not been filed. It was reported verbally on 12 September 2026 and the document has never arrived. The privacy impact assessment, the model card and the bias evaluation all follow launch rather than preceding it, by the same decision.

Because of that, every label written under the new default carries the marker legal_opinion_pending — computed under the platform's default policy, a written opinion requested and not yet filed. The in-product notice says the same thing. The marker is a disclosure that is true, and it stays until the opinion is filed.

[ENGINEERING NOTE] Labels written today carry the older marker not_for_a_real_campaign_before_a_legal_opinion, which is accurate now — the feature is still off by default and has only ever run on synthetic data. The rename to legal_opinion_pending lands in the same pull request as the default change, so that no label ever carries a marker that lies. Rows written before that change keep the old marker, because the table is append-only.

What does not change, and is the part that protects people:

Reading a label still requires the Restricted Data grant, with dual control. The default changes what is computed, not who may see it.
A trait a person states about themselves outranks the model's guess, always.
No message is ever selected from a trait.
A trait visible to a role that must not see it is a release blocker, and this decision does not touch that.
A Québec organization starts with labelling off, pending the compliance model, because Law 25's automated-decision provisions and the CAI notice duties were raised in the privacy brief and are unanswered. [ENGINEERING NOTE] the province is captured at sign-up for this purpose; the capture and the default both land with the labelling change in Phase 2.

Questions this policy cannot answer and counsel must: whether inferring ethnicity, faith or language from a name is processing of sensitive information requiring express consent — which, for an elector who never signed up, cannot be obtained; whether it triggers automated-decision-making provisions; and whether the prohibitions in §4.3 are sufficient protection or whether the feature needs conditions this policy does not contain.

Appendix B — where data is processed

Not the subject of this policy, and set out properly in the privacy notice. It is here because customers ask about it in the same conversation.

Canadian data residency is set aside through launch by the Product Owner's decision (61). There are four disclosed exceptions, each carrying a row in the sub-processor register, and none of them carries voter data:

Identity Platform (authentication records) — e-mail address, sign-in timestamps.
Identity Platform's mailer (sign-in links) — the recipient's address and a single-use link.
Google Workspace SMTP relay (the platform's own mail) — the recipient's address and the message.
Stripe (billing) — the organization's name, the administrator's address, the billing address and the card, entered on Stripe's own page and never reaching Field OP.

Everything else — the database, the API, the console, file storage, the map tiles and the labelling model — runs in Canada.

End of draft. Prepared by engineering for counsel, 15 September 2026. Sources: docs/master/Handoff_Master_v0.5_Part2.md §55, §56, §57, §59, §60; docs/decisions/2026-09-15-launch.md decisions 59, 61, 63, 64, 70; docs/legal/Privacy_Notice_Brief.md; docs/subprocessors.md; docs/plans/2026-09-15-to-launch.md B.3, B.4, C.5; and the migrations named in the engineering notes.