Field OP — Data Processing Terms

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 /data-processing and at /data-processing/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, and it is not in force.

It was written by the engineering side of the project so that counsel has something concrete to react to instead of a blank page. Counsel replaces it. Every clause is open to being rewritten, deleted or reversed.

What this draft does try to get right is the facts. Every statement below about what the platform does was checked against the code, the schema and the decision record on 15 September

1. Where the specification describes an intention that is not built, this draft says so in a

bracketed note rather than promising it. Where the master leaves a question open, this draft marks it [OPEN — counsel] and does not invent an answer.

These terms are intended to be accepted together with the Terms of Service at sign-up, and served at /data-processing. Neither page exists yet.

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" below means the platform. "Gestalt" means the contracting company. "you" and "the client" mean the campaign, party, riding association, advocacy organization or other organization that holds the account.

(§57 locks the contracting entity. It also notes that a planned spin-out into a separate company will need novation or assignment wording. [OPEN — counsel]: the assignment clause.)

[OPEN — counsel] The role question, which everything else hangs from. The privacy brief's §2 asks whether Gestalt is a service provider or processor to the campaign, or a controller in its own right, and whether the answer changes by tenant type — a municipal candidate, a provincial party, a third-party advertiser. The platform is multi-tenant and Gestalt operates it; the client decides who is contacted. This draft is written on the processor assumption because that is how the product behaves, and it must not ship on an assumption.

2. Words used here

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:

1. Individual rights. A person's rights in their own information are theirs, not yours and not ours.
2. 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.
3. Field OP's limited processing licence — §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.

(Master §58.1 is the source for this section.)

4. Models — the distinction that has to be explicit

The master requires this distinction to be written into the contract in terms, so here it is in terms.

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 or exported to you.

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. This is ADR-028, accepted 6 September 2026: scoring models train per tenant on that tenant's data plus non-personal aggregates; platform-level models train only on de-identified aggregates or licensed data; no cross-tenant training or feature transfer without a contract.

What is true today, which counsel should know before drafting around this. No per-tenant trained model exists in the platform right now. The one model that ships — the name classifier — is a single platform-level artefact generated from a synthetic name generator (packages/core/src/inference/onomastic-model.ts), and it is built from no client's data at all. The only thing that learns per client today is the calibration table in §8. So this clause is forward-looking. It should still be written now, because the first per-tenant model will arrive in a release and not in a negotiation.

And the closeout half is not built. "Destroyed or exported at closeout" describes a wind-down path that does not exist: the platform has no tenant closeout feature. §11 says what it does have.

[OPEN — counsel] Per-tenant model treatment at closeout — destruction, export, format, who attests, how long the client has to ask — is one of the master's six "still to define" items and is listed again in §13.

5. What Field OP may do with Client Data

Gestalt processes Client Data to:

• deliver and secure the service;
• provide support;
• perform integrations the client has approved;
• comply with law and with this contract;
• generate approved telemetry (event names, tenant and effort identifiers, role, surface, release version, outcome — never record content);
• create de-identified aggregate operational benchmarks under the safeguards in §8;
• train per-tenant models for that client's 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 one is backed by a build rule rather than a promise. The repository forbids any third-party name-classification or demographic-inference API anywhere, Canadian region or not (docs/subprocessors.md, "Forbidden"). A Vertex AI backend for the name classifier was written in September 2026 and then removed for exactly this reason; the classifier that shipped is in-house and makes no external call. The approved Vertex AI row is scoped to allowlisted context with no restricted notes, traits or protected characteristics.

6. Sub-processors

The register is the list. docs/subprocessors.md 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 (repository rule 6). A new destination — Canadian or not — is put to the Product Owner before it is used and recorded in the register first.

Notice to clients. The register is published, and a client is told before a new destination is used. The working proposal is the published page plus notice by email, thirty days ahead of first use.

Not built yet. Today the register is a file in the repository, not a page on the website, and there is no mailing mechanism. Publishing it and embedding it in the privacy notice from one source is planned work (plan §B.4 and §C.5). Until it is built, the notice commitment above is a promise, not a control.

[OPEN — counsel] The notice period (thirty days is engineering's proposal, not a decision), what a client may do on receiving notice, and whether an objection right or a termination right attaches.

7. Where processing happens

Everything that matters runs in Canada: the database, the API, the console and file storage in Google Cloud Toronto (northamerica-northeast2), AI inference in Montréal (northamerica-northeast1), the basemap served from Field OP's own bucket, geocoding from a self-hosted registry. Cloud Scheduler runs in Montréal because Google does not offer it in Toronto; a timer holds a cron expression and a job name and no data at all.

Canadian data residency is set aside through launch by the Product Owner's decision of 14 September 2026, restated 15 September (decision 61). The residency rule is not repealed; it is being consciously spent, four times. There are four exceptions and no others:

None of the four carries voter data. Identity Platform holds the directory of who may sign in — campaign staff, volunteers, administrators, candidates — and no record about a member of the public. The two mail paths carry an address and a message. Stripe holds the billing contact.

What would reverse the decision, per decision 61: a design partner whose contract requires residency, counsel's answer on the voters'-list custody terms, or the Québec compliance question.

Register lag to fix before launch. The register carries rows for Identity Platform and its mailer. It does not yet carry rows for the Workspace relay or for Stripe; both are recent decisions (58 and 63) and the rows are outstanding work. Counsel should not read the register's current contents as the complete list — decision 61's table above is.

8. Benchmarking, and the one deliberate cross-tenant read

8.1 The position

Raw tenant data stays tenant-bound. Tenants 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, under the master's §34.5 cohort rules: a minimum of ten campaigns 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; the segment is broadened rather than a small cohort exposed.

What is never benchmarked: support for a candidate, opposition, individual characteristics, or a client's strategy. Operational performance only. De-identified model performance may be benchmarked.

Not built. There is no benchmarking feature in the platform today — no cross-client metric, no cohort, no floor, no screen. This clause describes what would be permitted if one were built. The only thing that actually crosses tenant lines today is §8.2.

8.2 Pooled calibration — disclosed plainly, because it is real

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. Decision 39 (Product Owner) makes those counts pooled across campaigns by default, so every campaign's model improves from every campaign's doors.

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 campaign that shares. A campaign 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 that returns three columns — signal, stated, count — and only a caller whose own campaign shares may read it.

How a client opts out. In the console, under Admin → Labelling, a tenant 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 the campaign feeds nothing into the pool and reads only its own counts. The same screen carries a second choice: if the campaign is ever deleted, its counts are either kept in the pool with nothing saying whose they were, or deleted with it. A campaign that had opted out contributes nothing on deletion either way.

The honest residual risk, which counsel should be told rather than discover. Nothing in the pool is about a person. It is aggregate information about a campaign's canvass: with very few sharing campaigns, a participant could in principle subtract its own counts and see what remains. The master's ten-campaign floor in §34.5 exists for that shape of leak, and no minimum-contributor floor is implemented in the pool today. The counts say nothing about support or strategy — only about names and languages — and with one campaign on the platform the risk is nil. It becomes real, and small, as campaigns join.

Review gate H08 — cross-tenant access and sharing — is the master's own release gate for exactly this, and its state is still Hold. A tenant configuration switch cannot close it; a record can. Producing that record is on the Product Owner's list as a trailing item.

[OPEN — counsel] Whether pooled aggregate calibration is a processing of personal information at all, and if so on what basis; whether a deleted campaign's unattributed contribution staying in the pool raises anything under retention or deletion duties; and whether the default should be on. This is question 5 of the privacy brief's §6 and it is already with counsel.

9. Inferred traits

This is the sharpest thing in these documents and it is set out exactly.

Field OP includes a model that reads a person's family name and produces a belief about their language, ethnic community or religion. By the Product Owner's decision of 15 September 2026 (decision 64):

• It is on by default for a new organization, as a matter of platform policy.
• A tenant administrator may switch it off at any time, and labels stop being produced immediately.
• A written legal opinion on the feature has been requested and has not been filed. So has the privacy impact assessment, the model card and the bias evaluation; the Product Owner's decision is that these follow launch rather than precede it, overriding the master's own gate at §41.4.
• Every label written in the meantime carries the marker legal_opinion_pending — computed under the platform's default policy, opinion requested, not yet filed — and the admin screen says so.

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, approved by a second administrator. 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 taken as an input 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 (decision 39).
• No message is ever selected from a trait.
• A phone never holds a restricted or inferred field, by construction.
• 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.
• A Québec organization starts with labelling off, pending the compliance model, because Law 25's automated-decision provisions and the CAI notice duties are unanswered. The province is captured at sign-up for this reason.

What is true in the code on 15 September 2026, stated so this clause is not read as a description of today. The schema default for labelling is still off (migration 0051), and labels written so far carry the older marker not_for_a_real_campaign_before_a_legal_opinion. Decision 64's default change and the marker rename land in the same pull request, deliberately, so that no label ever carries a marker that lies. Until that release ships, the paragraph above describes the position at launch rather than the position today.

[OPEN — counsel] Master §56.2 says inferred traits "are not used to select messages unless a tenant explicitly enables it". Decision 64 is later and absolute: no message is selected from a trait. Confirm which binds; this draft carries the decision.

[OPEN — counsel] Everything in §6 of the privacy brief: whether inferring ethnicity, religion or language from a name is processing of sensitive information under whichever statute applies; whether express consent is required, which for an elector who never signed up cannot be obtained; whether automated-decision provisions are triggered; and what a person must be told if they ask what this campaign believes about them and why.

10. Individual rights

A person's rights run against the client campaign, which decides who is contacted. Gestalt supports the client in answering them.

What the platform can actually 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 the campaign.

[OPEN — counsel] Who answers a request and in what time; what the notice says about immutable records; whether Gestalt must offer a direct route; and whether a privacy officer must be named and who that is. None of these is settled.

11. Retention, export and closeout

Export. A client can take its 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, and expires. Restricted and inferred classes are refused from an export by the authorization evaluator before any grant is considered. A campaign in read-only standing for non-payment can still read, export and pay, which is deliberate.

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.

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. Actually destroying copies and collecting each holder's written confirmation is a later release. These terms must not say the platform deletes data on a schedule. It does not. There is also no tenant wind-down path at all, which matters because an election campaign is temporary by nature.

[OPEN — counsel] Export rights as a contractual matter: what a client is entitled to, in what format, within what period, at what price, for how long after termination, and what happens to the per-tenant model and the calibration counts at that moment.

12. Security

Stated conservatively, and each of these is enforced and tested: tenant isolation at the database by row-level security; role-based access with a closed vocabulary a campaign cannot extend; restricted classes behind a separate expiring grant approved by a second administrator; 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 CI over every audit payload in the system; absolute session expiry; re-authentication for dangerous acts; encryption in transit and at rest.

Not true yet, and not to be claimed: no penetration test has been performed, there is no SOC 2 or equivalent attestation, and breach notification procedures are not written.

[OPEN — counsel] The breach clause: statutory duties by jurisdiction, who notifies whom, and in what time. A skeleton procedure is planned; the duties are counsel's.

13. Still to define

The master lists six things as still to define before Phase 2. None is answered here, deliberately.

1. The exact de-identification standard — what "de-identified" means as a testable threshold.
2. Client opt-out rights — which processing a client may decline, and by what mechanism. The calibration opt-out in §8.2 is built; nothing else is.
3. The processing licence — the scope and duration of the licence in §3(3) and §5.
4. Export rights — §11.
5. Per-tenant model treatment at closeout — §4.
6. The treatment of proprietary model improvement — where the line falls between an improvement that is generic and ours, and one that is derived from a client's data.

Open in the Terms of Service and carried here because they bear on this document: governing law and jurisdiction (Ontario is engineering's suggestion and nothing more), the liability cap, the service commitment — there is no uptime commitment today and the terms should not imply one — and pilot and beta terms.

14. 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 the client was actually shown. When counsel's text arrives it becomes the next version, and the "not yet" clause in §9 comes out with it.

Draft prepared 15 September 2026 from Handoff Master v0.5 Part 2 §58, decisions 39, 53, 58, 61, 63 and 64, docs/subprocessors.md, the privacy notice brief of 11 September 2026, and the launch plan of 15 September 2026. Factual statements were checked against the code and schema on that date. Not legal advice; not in force.