Field OP — Data Processing Terms
Version: 1.0-draft Published at: /data-processing and /data-processing/1.0-draft Effective: not in force. A version that is not a draft takes effect on publication.
This version is engineering's, and it is not in force. It was corrected on 17 September 2026 by checking every sentence about what the platform does against the code that does it. No lawyer has reviewed it, nobody has been asked to accept it, and it stays a draft — the page carrying it says so before the text — until a version counsel has cleared replaces it.
These terms are accepted together with the Terms of Service at sign-up and form part of them. Where these terms and the Terms of Service conflict on the processing of Client Data, these terms govern; on anything else, the Terms of Service govern.
1. Who these terms are between
These terms are between Gestalt Communications Inc., a company incorporated federally in Canada, and the client organization that signs up. Field OP is a product of Gestalt Communications Inc.
"Field OP" means the platform. "Gestalt", "we" and "us" mean the contracting company. "You" and "the client" mean the campaign, party, riding association, advocacy organization or other organization that holds the account.
Roles. For Client Data about members of the public, you decide what is collected and why, and we process it on your instructions. You are accountable to those individuals; we support you in answering them. For the records we hold about the people who use the Service — accounts, sign-ins, audit records, telemetry — we determine the purposes and are accountable directly.
2. Words used here
| Term | Meaning in these terms |
|---|---|
| Client Data | Everything you put into Field OP, or that Field OP records for you about people: electors, supporters, contacts, and your own staff and volunteers. |
| Campaign-generated records | What your own work produces — doors knocked, conversations, survey answers, tags, consents, suppressions, shifts. |
| Restricted source data | Data from an electoral list or another source carrying its own conditions, which the platform tracks separately from campaign-generated records. |
| Inferred trait | A label the platform computes rather than records — see section 9 and the Inferred Trait Schedule. |
| Calibration counts | Aggregate integers about how often a guess matched what a person later said — see section 8. |
| Per-tenant model | A model trained on one client's data for that client's use. |
| Platform model | A model Field OP builds from de-identified aggregates or licensed data. |
3. Who owns what
You keep your rights in Client Data and in campaign-generated records. Signing up does not transfer them to Gestalt. That is subject to three things, and they are real limits rather than boilerplate:
- Individual rights. A person's rights in their own information are theirs, not yours and not ours.
- Source restrictions. Data from an electoral list arrives with conditions attached — what it may be used for, how long it may be kept, who must sign for a copy. Those conditions travel with the data and neither party can contract them away.
- Field OP's limited processing licence — section 5 below.
Gestalt and Field OP own the platform. That means the software, the product design, the generic workflows, the documentation, the security architecture, the orchestration systems, and generic improvements to the product. If your use of Field OP teaches us that a screen is confusing or a workflow is wrong, the better screen is ours.
4. Models — the distinction that has to be explicit
A per-tenant model trained on your data is associated with you. Specifically:
- it is not transferred to another client;
- it is not reused for another client;
- it is not sold;
- at closeout it is destroyed. It is not exportable.
The method is ours. The modelling technique, the features, the pipelines, and any platform-level model built on de-identified aggregates or on data we license are Field OP's and stay Field OP's. Scoring models train per client on that client's data plus non-personal aggregates; platform-level models train only on de-identified aggregates or licensed data. There is no cross-client training or feature transfer.
The name classifier described in section 9 is a platform-level model of ours, generated from a synthetic name source and built from no client's data. The labels it writes about your people are Client Data.
5. What Field OP may do with Client Data
Gestalt processes Client Data to:
- deliver and secure the service;
- provide support;
- perform integrations you have approved;
- comply with law and with this contract;
- generate approved telemetry — event names, organization and effort identifiers, role, surface, release version, outcome, and never record content;
- create de-identified aggregate operational benchmarks under the limits in section 8;
- train per-tenant models for your own use.
And two sentences that are the point of the section:
Field OP does not sell Client Data, or voter and contact data.
Field OP does not train general third-party models on client content.
The second is backed by a build rule rather than a promise. The repository forbids any third-party name-classification or demographic-inference service anywhere, Canadian region or not, and a change that introduces one fails review. See the sub-processor register.
6. Sub-processors
The register is the list. It records every external destination the platform talks to: what it is for, what data is sent, where it is processed, whether it is approved, and whether it is actually in use. Approval and use are different facts and the register separates them.
Adding a destination is a decision, not a deployment. A change that adds an external network call without a register entry fails review. A new destination — Canadian or not — is approved before it is used and recorded in the register first.
Notice. We will give you at least thirty days' notice before a new sub-processor begins processing Client Data. You have no right to object; if a change is unacceptable to you, your remedy is to stop using the Service and cancel under section 13 of the Terms of Service.
Flow-down. We remain responsible to you for a sub-processor's handling of Client Data as if it were our own.
7. Where processing happens
Everything that matters runs in Canada: the database, the API, the console and file storage in Google Cloud Toronto; AI inference in Montréal; the basemap served from Field OP's own bucket; geocoding from a self-hosted registry. One Google timer service runs in Montréal because Google does not offer it in Toronto; it holds a schedule and a job name and no data at all.
There are six exceptions to Canadian residency and no others, each carrying a row in the register:
| Exception | What crosses |
|---|---|
| Identity Platform (authentication records) | Email address, sign-in timestamps, phone number, password hash, second-factor secret — campaign staff and volunteers only |
Google's own sign-in endpoints (accounts.google.com, oauth2.googleapis.com) | A person's own Google sign-in during "Continue with Google", conducted between them and Google — campaign staff and volunteers only. Basic scopes; neither the name nor the picture is read out of the token |
Microsoft Entra ID (login.microsoftonline.com) | A person's own Microsoft sign-in during "Continue with Microsoft", on the same basic terms and with the same nothing read out of it |
| 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, never reaching Field OP |
None of the six carries voter data. Identity Platform holds the directory of who may sign in and no record about a member of the public. The two sign-in providers carry a campaign worker's own sign-in with their own provider, and nothing else. The two mail paths carry an address and a message. Stripe holds the billing contact.
The two sign-in providers were added on 17 September 2026, when "Continue with Google" and "Continue with Microsoft" went live. Microsoft is the only one of the six that is neither Google nor Stripe.
Google's default log buckets are global. Operational logs are scrubbed of personal details by field name and by value shape before they are written.
8. Benchmarking, and the one deliberate cross-client read
8.1 Benchmarking
Your raw data stays bound to your organization. Organizations cannot see each other's data, and that is enforced by row-level security in the database rather than by application code remembering to check.
Approved operational metrics may be turned into de-identified aggregate benchmarks.
[NOT YET BUILT — 17 Sep 2026] No benchmarking feature exists. There is no cross-client metric, no cohort, no floor and no screen. The cohort rules below bind Gestalt when one is built; they do not describe anything running today.
The cohort rules are:
- a minimum of ten organizations before a benchmark is shown;
- a cohort is suppressed where one client contributes an outsized share, or where the comparison could reasonably reveal a specific campaign;
- where a cohort would be too small, the segment is broadened rather than the small cohort exposed.
Benchmarks are computed only from operational telemetry — how the Service is used. What is never benchmarked: support for a candidate, opposition, individual characteristics, inferred traits, or a client's strategy. De-identified model performance may be benchmarked.
8.2 Pooled calibration counts
When the model guesses something from a person's family name and that person later tells a volunteer the answer themselves, the platform counts the pair.
What is in a cell: the kind of guess, what the model said, what the person said, and how many times. Four values, the last an integer.
What crosses: those counts, summed across every organization that shares. An organization that shares reads the pooled totals and contributes to them.
What does not cross: any person, any name, any record identifier, any address, any contact detail, any campaign-generated record, anything about support or strategy. Nothing in the pool can be joined back to a person. The read is a single database function returning three columns — signal, stated, count — and only a caller whose own organization shares may read it.
How you opt out. In the console, under Admin → Labelling, an administrator holding the Intelligence grant clears the checkbox that reads "Learn together with every other campaign on the platform (counts only), and let them learn from this one." From that moment your organization feeds nothing into the pool and reads only its own counts. The same screen carries a second choice: if your organization is ever deleted, its counts are either kept in the pool with nothing saying whose they were, or deleted with it. An organization that had opted out contributes nothing on deletion either way.
The residual risk, stated rather than left to be discovered. Nothing in the pool is about a person. It is aggregate information about a campaign's canvass, and with very few sharing organizations a participant could in principle subtract its own counts and infer something about what remains. There is no minimum-contributor floor today, so nothing in the platform prevents that: the pooled read sums every sharing organization's counts and applies no threshold. What bounds the risk is what a count can say, and a count says nothing about support or strategy — only about names and languages.
9. Inferred traits
Field OP includes a model that reads a person's family name and produces a belief about their language, ethno-cultural community or religion. The platform computes other kinds of estimate as well; the full list is in the Inferred Trait Schedule, which forms part of the Terms of Service.
- Labelling is on by default for a new organization outside Québec, as a matter of platform policy. An organization that gives a Québec address at sign-up starts with it off and with no kind enabled at all.
- An administrator may switch it off at any time, and labels stop being produced immediately.
- Only the kinds of estimate the organization has enabled may be written; the writer refuses any other kind. Outside Québec a new organization is enabled for six kinds; the database's own list of permitted kinds is wider, and the Inferred Trait Schedule names the whole of it.
- Every label carries a marker recording the platform policy, the model and the model version under which it was computed.
What the default does not change, and this is the part that protects people:
- Reading a label requires the Restricted Data grant, with dual control: a separate, expiring grant on top of a role, naming a second administrator — and the database itself refuses a grant that names the person who requested it or the person who receives it. Nobody is asked to approve it: there is no pending state and no notification, and the grant counts from the moment it is issued. The default changes what is computed, not who may see it.
- A trait a person states about themselves outranks the model's guess. The statement is weighted heavily enough to dominate on its own, every new statement is captured rather than the first being frozen, and a later conflicting statement is resolved.
- No message is ever selected from a trait. A script variant may select only on fields the mission bundle already carries plus the language a person stated.
- No one is included in or excluded from contact on a score. The rule language that would allow it is switched off everywhere and matches nobody.
- A phone never holds a restricted or inferred field, by construction, and an inferred class is refused from an export before any grant is considered.
- A label is an estimate, never a fact, and can be confirmed, corrected, rejected or disabled by a person. Low-confidence guesses are stored and never shown.
Gestalt does not represent that this feature is lawful in your jurisdiction, and you should take your own advice before relying on it. You are responsible for your targeting and messaging decisions, including decisions made using model output.
10. Individual rights
A person's rights run against you, because you decide who is contacted. We support you in answering them.
What the platform can do today: show everything held about a person; show where each fact came from, who recorded it and what it superseded; correct a fact by writing a new assertion rather than overwriting; withdraw consent per channel and purpose with the exact wording version recorded; record a do-not-contact instruction that propagates to the household and reaches the phone; export; reject an inferred label.
What it cannot do: hard-delete. Records are soft-deleted and retained, and hard deletion is revoked at the database for the application role across the tables that hold campaign data. Some records are deliberately immutable — the audit trail, custody acknowledgements and destruction certificates are append-only evidence. There is no self-service portal for a member of the public; the route is through you.
Our response time. Where you ask us to act on a request, we respond within thirty days and will tell you if we need longer and why.
11. Retention, export and closeout
Export. You can take your data out. An export names its purpose in writing, lists its fields explicitly, refuses a class that may not leave rather than quietly dropping the column, records a row in the copies register, needs re-authentication less than five minutes old, is downloadable once, by the person who asked for it, and expires after 24 hours. Restricted and inferred classes are refused by the authorization evaluator before any grant is considered. An organization in read-only standing can still read, export and pay, and an organization in suspended standing can still export and pay, which is deliberate: your data is yours, and you may be under a deadline to account for a voters' list.
[NOT YET BUILT — 17 Sep 2026] True of read-only standing, and not of suspended. A suspended organization can sign in and can pay — that much was built on 17 September 2026 — but the permission evaluator allows a suspended organization billing and nothing else, so an export is refused. The sentence is kept because it is what we intend and because a campaign holding a voters' list may be under a statutory deadline; it is marked because the platform does not do it today.
Retention. Each data source carries its own retention rule and destruction date, and anybody who takes a copy signs an undertaking naming both. Every export, walk sheet and phone bundle drawn from a source is recorded with who received it, so outstanding copies can be counted at any moment. Phone bundles expire at the end of the canvass window or 24 hours, whichever is sooner, and the device purges 12 hours later. Sessions expire absolutely at 12 hours, but for two named phone paths — uploading the conversations recorded at doors, and reporting a safety event.
Closeout. For thirty days after your subscription ends you may export. After that we delete or de-identify Client Data within ninety days, except for the audit trail, custody acknowledgements, destruction certificates, billing records, and anything subject to a legal hold. Any per-tenant model is destroyed.
[NOT YET BUILT — 17 Sep 2026] The thirty days and the ninety days are the intention, not a description. There is no wind-down path in the platform at all: nothing marks a subscription as ended, nothing opens an export window, and nothing deletes or de-identifies an organization's data when it closes. The export itself is built and works today. The promise is kept here because it is meant, and marked because the mechanism behind it does not exist.
The honest gap. Carrying out a destruction is not built. The platform records the undertaking, tracks every copy, and can produce a certificate stating what was outstanding and who held it at a moment in time — and the certificate says in terms that it is not evidence that anything was destroyed. These terms do not say the platform deletes data on a schedule, because it does not. Actually destroying copies and collecting each holder's written confirmation is yours to do.
12. Security
Stated conservatively, and each of these is enforced and tested: organization isolation at the database by row-level security; role-based access with a closed vocabulary you cannot extend; restricted classes behind a separate expiring grant that is dual-controlled, the database refusing one that names the person who requested it or the person who receives it, and nobody being asked to approve it; no restricted data on a phone by construction; signed mission bundles; an immutable audit trail that records which record changed, by whom and the shape of the change, and never the content — checked in the build over every audit payload in the system; absolute session expiry; re-authentication for dangerous acts; encryption in transit and at rest.
Not claimed: there has been no penetration test, and there is no SOC 2 or equivalent attestation.
Breach. Where a breach of security safeguards affects your Client Data, we notify you without undue delay and give you what you reasonably require to meet your own obligations. You are responsible for notifying the individuals whose information you hold and for any report you must make to a regulator. We keep a record of every breach. Our notification to you is not an admission of fault or liability.
Audit. On written request, not more than once in any twelve-month period, we will provide a written description of our security controls and answer reasonable questions about them. This does not extend to access to our systems, our premises, or another customer's data.
13. How these terms change
These terms are versioned. A version is never edited: a change is the next version, with the exact wording and its hash recorded, and acceptance is recorded against the version you were actually shown.
Field OP is a product of Gestalt Communications Inc.