Effective 8 August 2026. This addendum forms part of the service agreement between People Purpose Corporation and the client company that subscribes to Quadrant.
This is a draft. It has not been reviewed by a lawyer. It was written from the source code of the product, so that it describes what the software actually does rather than what a template says it should do. It is published so that a client's counsel can read it and mark it up. Until a lawyer has reviewed it and Rod has signed off, treat it as an honest description of the system and a proposed set of commitments, not as executed contract language.
Nothing in this document was guessed at. Where a fact could not be established from the source code it was left blank rather than invented, and the remaining open items are listed together in section 20.
Contents
People Purpose Corporation ("People Purpose", "we", "us"), a corporation incorporated in Manitoba, Canada, operating the Quadrant service at disc-quadrant.com. Registered office: 7 Fox Run, Kleefeld MB, R0A 0V2, Canada. Contact: Rod Penner, rod@people-purpose.com.
People Purpose is a sole-operator business. One person operates the platform, holds the production credentials, and answers privacy correspondence. That is stated plainly because it is relevant to several of the commitments below, particularly audit and breach response.
The Client ("you"), the company that has subscribed to Quadrant and whose employees and applicants are the subject of the processing described here.
This addendum covers personal information about your people — your job applicants, your employees, and the people your staff enter into Quadrant — that we process because you use the service.
It does not cover:
Applicable law. The federal Personal Information Protection and Electronic Documents Act (PIPEDA) applies to this processing. If you are a provincially regulated employer in Alberta or British Columbia, the Personal Information Protection Act of that province applies to your employee and applicant information instead, and both statutes have specific rules for "personal employee information" that let an employer collect, use and disclose it without consent where that is reasonable for establishing, managing or ending the employment relationship, provided the individual has been given notice. Where those rules apply, the notice obligation is yours, not ours. Canada's anti-spam legislation (CASL) governs commercial electronic messages.
Quebec. Quebec is not a market we sell into. We have not built for Quebec's Law 25 and we do not claim to comply with it. If you have employees or applicants in Quebec, tell us before you sign, because this addendum does not cover you.
Quadrant sits in the middle of three different relationships. Most confusion about privacy in a product like this comes from mixing them up, so they are kept separate throughout this document.
Nothing in Quadrant charges a job seeker anything. Candidate-side use of the product is free and always will be.
You decide the purposes. For your applicants and your employees, you are the organisation that decides why the information is collected and what it is used for. You choose to open a role, to invite an applicant, to send your team the assessment link, to run a review, to write a note about someone. You are responsible under PIPEDA (or Alberta or BC PIPA) for having a basis to do those things, for telling the individual what you are doing, and for making sure your own use is reasonable.
We process on your instructions. We hold and handle that information to deliver the service to you. We do not decide, for your people, what the information is for.
Canadian privacy law does not use the words "controller" and "processor" the way European law does. It puts the accountability on the organisation that has the information, and lets that organisation transfer it to a third party for processing under contract while remaining accountable for it. This addendum is that contract. If your counsel prefers the controller/processor vocabulary, you are the controller and we are the processor, and we will not argue about the label.
There are places where we are not acting on your instructions. Rather than bury them, here they are.
Anyone can take the assessment on our public site, use the leadership tool, or use the read-a-person tool without any connection to a client company. Those runs are filed to our own platform account, not to yours. We decide the purposes for those. If one of your employees uses a free public tool on their own time with their own email, that record is ours, not yours, and it is not visible in your dashboard.
People who ask for our emails go on our own subscriber list. Consent is recorded when they sign up. Every marketing email carries a one-click unsubscribe. That list is ours. We do not add your employees or your applicants to it because they passed through your account.
We use your administrators' account information to operate the account, bill it, and support it. We count the people on your roster each day to set the per-person quantity on your subscription. We use aggregate, non-identifying information about how the product is used to keep the product working. Those are our purposes.
People Purpose does recruiting work as well as software, and keeps its own pool of people who came to us directly. Section 10 explains exactly what does and does not move between that pool and your account today.
Several automatic emails to applicants are blind-copied to jobs@disc-quadrant.com, which is our address, so we receive a copy of every application-received confirmation sent from your account. Two internal notification emails — a "review ready" alert when both sides of a check-in are in, and an internal alert when a client's team crosses an activity threshold — currently default to rod@people-purpose.com rather than to you. Those are operational artefacts, not a product feature. They are disclosed here because they mean our own mailbox holds copies of some of your people's information.
| Category | What is in it |
|---|---|
| Identity and contact | Name, email address, phone number, company, job title, region. No home or street address is collected from anyone. |
| Application material | Resume text, the uploaded resume file itself, what the person is looking for, current role, answers to the role questions you set, and the advisory flags those answers produce. |
| Assessment answers | The full set of raw answers to the DISC forced-choice items, the character items, and the most/least blocks, stored verbatim. Whether the person said they are currently employed. If they said yes, three further questions about commitment to their current employer, which are shown only to people who said yes. |
| Derived scores | Normalised DISC percentages, primary and secondary style, five character measures each stored as a self-rating, a behaviour-based rating, and the gap between them, a drive measure, and consistency ("candour") flags. For employees, a set of five "how to manage me" preferences. |
| Written narrative | Generated reports, interview kits, fit reads, and role-alignment reads, each stored against the person. |
| Employment and review content | Job description text and files, review scorecards, both the employee's and the manager's ratings and notes, and free-text notes your staff write on an application. |
| Interview material | Interview transcripts your staff paste in, up to a large size limit. |
| Development records | Growth Program state and progress, including the person's raw quiz answers and a free-text reflection, and certificates carrying their name and company. |
| Account and technical | Login records held by our authentication provider, including email, password hash, last sign-in and email-confirmed timestamps. The IP address of whoever submits an assessment, stored on the assessment record and used to rate-limit submissions. The IP address of anonymous users of the read tool, stored with a date. Timestamps, and how long a person took to complete the assessment. The email address of the staff member who took each action, stamped on stage changes, notes, reads and reviews. |
We do not ask anyone for health information, race, religion, sexual orientation, union membership, criminal record, or financial details, and no field in the product requests them. But several fields are free text — resumes, notes, interview transcripts, job descriptions, the read-a-person input — and a person typing into a free-text box can type anything. What goes into those boxes is under your control, not ours. If your staff type sensitive information into a note, it is stored as typed.
The assessment is a working-style questionnaire and a set of character measures. It is not a medical or clinical instrument and is not offered as one.
We may process your people's information only to provide and support the service. Concretely, that means:
We will not sell your people's information. We will not use it to train a general-purpose model of our own. We will not use it to market to your people. We will not disclose it to another client company. The one place where the boundary between accounts has historically been imperfect is described in section 10, in full.
Your instructions to us are: the service agreement, this addendum, and what your staff do in the product. If you want us to do something outside that, put it in writing to rod@people-purpose.com.
If we think an instruction would put us in breach of Canadian privacy law, we will tell you and we will not carry it out until it is resolved.
If we are legally compelled to disclose your people's information — a court order, a warrant, a lawful demand — we will tell you before we comply, unless the law forbids telling you.
No one is rejected automatically. There is no code path in Quadrant that sets an applicant to rejected without a person clicking to do it. The assessment informs hiring decisions. It does not make them, and it is not a measure of whether someone can do the work.
Three calculations run automatically and you should know how each one behaves.
When you have set a target profile for a role, the product can rank people against it. The number is arithmetic, not AI: it compares the person's DISC percentages against the target, and for each of the five character measures it counts only the shortfall below target, so exceeding a target costs nothing. The two halves are averaged.
This number has not been validated. The code says so itself, in a comment kept in the source deliberately: nobody has run an adverse-impact study on it. It is a sorting aid for a human, and you should treat it as one. Do not use it as a cut-off.
It appears on your list of applicants and nowhere else. The interview guide, which your staff open with one named candidate in front of them, is not given the number: the server drops it, along with its two sub-scores, before the response leaves us, so the browser never receives it. That page shows the per-measure comparison instead — which of the five character measures sit at or within five points of the role's target, and which sit further under it, each carrying the target and what the person showed.
If your staff ask for it, the product sends a resume and the job description to Anthropic's Claude and asks for a 0-100 number and a short written read on how the experience lines up with the role. That number is stored on the application record. It is a language model's judgment, produced on request by a member of your staff, and it carries the same caution: it is input to a human decision, not a decision.
If you set role questions on a posting, the applicant's answers produce advisory flags. The applicant is told, on the page, that nothing there rejects them automatically and that their answers go to the hiring team as notes for a person to read. The code carries the same instruction in a comment. Flags are stored on the application and shown to your staff.
And nothing is automatically advanced either. There is no branch anywhere that invites an applicant to interview, or moves them forward in any way, without one of your staff doing it. An applicant whose role-question answers produce no flags and an applicant whose answers produce flags receive identical email.
The cross-company talent pool is switched off. The scheduled job that would copy people out of a client account into a shared pool returns at its first line unless a server switch is explicitly set to "on". It is still on a daily schedule, and it does nothing.
It is paused because, as written, it strips the marker that identifies someone as a client's own employee. On production it had already mirrored twelve employees across four client companies into the platform pool, reading as recruitable, plus four records stamped with where someone had been hired. That contradicts the guarantee we make to clients. Those copies are being worked through.
Two things follow, and both are commitments under this addendum:
One route does still cross, and it is manual. A platform administrator can place a person from People Purpose's own recruiting pool into a client's pipeline by hand, one at a time. That branch is not behind the pause switch. That is us doing recruiting work for a client, not two clients trading databases.
We use the following services. This is the complete list of third parties that receive your people's personal information today.
| Sub-processor | What it does | What it receives |
|---|---|---|
| Supabase | Database, file storage and login accounts | Everything. All records described in section 6. Resume files and job description files are held in a private storage bucket and served to your staff through short-lived signed links that expire in ten minutes. |
| Netlify | Hosting and serverless functions | Every request to the service passes through it, so it sees IP addresses and request content in platform logs. Some of our own function logs include names and email addresses. |
| Anthropic | The AI behind reports, reads and drafting | See the breakdown below. This is the sub-processor that receives the most sensitive free text. |
| Resend | Sending email | Recipient address, name, and the full body of every message we send to your applicants and employees. |
| Stripe | Subscription billing | Your account identifier, your headcount, and your administrator's email address as the billing contact. No applicant or employee data reaches Stripe. |
| Google Analytics | Site analytics | Loaded on the assessment page, the pool intake page and most other pages, so it sees page views and whatever identifiers it sets in the browser of the person taking your assessment. It does not receive answers or scores. There is no cookie or consent banner on the site. [[DECISION NEEDED — ROD]] |
| Cloudflare (cdnjs) | Serving three browser libraries | Only the request for the script file itself, which exposes the visitor's IP address to Cloudflare. Resumes and job descriptions dropped into those pages are parsed inside the browser; the file contents do not go to Cloudflare. |
Because this is the question a careful buyer asks, here is the actual list. Each of these runs when a member of your staff asks for the feature, except where noted.
The read-a-person tool also sends Anthropic the raw text your staff paste in and the name of the person it is about. If your staff paste an email a third party wrote, that third party's words go to Anthropic.
Two things a reader of our code might expect are not in use, and we would rather say so than let you assume the worst. Twilio is wired up and proven but is not connected to any product flow, so no phone number collected in Quadrant is sent to it today. Adzuna is used only to pull public job listings in; no applicant information is ever sent out to it.
We will give you at least thirty days' notice by email to your account owner before we add a new sub-processor that will receive your people's information, or before we materially change what an existing one receives. If you object on reasonable privacy grounds within that period, we will work with you to find an alternative, and if there is none you may terminate the affected part of the service without penalty and get a pro-rated refund of anything you have paid in advance.
We have to be honest about the limits of what we know here, because a cross-border statement that turns out to be wrong is worse than no statement.
All of the sub-processors in section 11 are services we buy from third parties, and each of them may process outside Canada. Assume your people's information is processed outside Canada, including in the United States, and is therefore subject to lawful access by the courts and authorities of the countries where it is held. That is the assumption you should plan on and the assumption you should give your people notice about.
The specific region for each service is set out below. Where it says unconfirmed, it means we have not verified it and will not guess.
| Service | Processing region |
|---|---|
| Supabase (database, files, logins) | [[REGION — ROD TO CONFIRM IN THE SUPABASE DASHBOARD]] — the region is not discoverable from the source code. |
| Netlify (hosting, functions, logs) | [[UNCONFIRMED — ROD]] |
| Anthropic | [[UNCONFIRMED — ROD]] |
| Resend | [[UNCONFIRMED — ROD]] |
| Stripe | [[UNCONFIRMED — ROD]] |
Under PIPEDA a transfer to a third party for processing is a use, not a disclosure, and the organisation that transfers it stays accountable for it. That is us to our sub-processors, and you to us. The Office of the Privacy Commissioner expects the individual to be told, in a way they can understand, that their information may be processed outside Canada. That notice is your obligation to your employees and applicants. We will give you whatever detail you need to write it once the regions above are confirmed.
Whether we hold a signed data processing agreement with each of these providers is being worked through. [[CONFIRM SUB-PROCESSOR DPAs — ROD]]
This section describes only measures that exist in the running system. We claim no certification. We hold no SOC 2, no ISO 27001, and no third-party audit report, and we will not imply otherwise to close a sale.
Separation between client accounts is enforced in application code, not by the database. Server functions connect to the database with a secret key that bypasses the database's own row-level security. Every function then filters by account identifier itself. It works, and every read path in the product is scoped that way, but the guarantee is the correctness of our code rather than a rule the database enforces underneath it. Moving that enforcement into the database is planned work. You are entitled to know it has not happened yet.
A platform administrator can enter any client account. A super-administrator can pass an account identifier with a request and act inside that account as its owner, and passes role checks without doing so. This exists so that one person can support every client. Today there is no audit log of that access and no notification to you when it happens. Both are on the list to build. In the meantime the honest statement is: People Purpose can see everything in your account, and you cannot currently see when we did.
Encryption of data at rest is whatever Supabase and Netlify provide by default. We have not configured or verified anything beyond that and we do not claim a specific standard. We do not run our own backups; whatever backup and point-in-time recovery exists is the provider's. [[CONFIRM BACKUP POSTURE — ROD]]
Personnel. One person operates the platform. Access to production credentials is limited to that person. There is no other staff member with access to your data today. If that changes, anyone with access will be under a written confidentiality obligation before they get it.
Inside your own account, access follows the role you give someone:
| Role | Reach |
|---|---|
| Employee | Their own record only, matched to their own login email. They see their own style, their five health numbers, and how far apart their self-rating and their behaviour-based rating are on each character measure. They do not see their manager's notes. |
| Viewer, sales, marketing | Every assessment in your account: name, email, company, DISC, drive, candour flags and health scores, plus the full narrative report, and the ability to generate a new one. If you are giving out a "read-only" role expecting it to be limited to a subset of people, it is not. Assign it accordingly. |
| HR, admin, owner | All of the above plus the whole hiring side: candidate records, resumes, AI reads, notes, interview transcripts, reviews and the invitation tools. |
| Owner and admin only | Deleting a person or an assessment, and managing the team, including the full delete of a member's data. |
The asymmetry between an employee and their manager, stated plainly. The manager additionally sees the employee's email, their candour flags, their self-rating and behaviour rating separately rather than only the gap, their "how to manage me" preferences, the generated alignment read on how they sit against their role, the review ratings and notes from both sides, and the full narrative report. If you tell your team that Quadrant is a development tool, that is true, and this is the part you should tell them as well.
One report link is unauthenticated: a shareable report link is the assessment's own identifier, and anyone holding that link can open the scores, name, company and date without signing in. It is unguessable, but it is not access-controlled. Treat a shared report link as public and do not paste it anywhere you would not paste the report.
When one of your employees or applicants asks to see, correct or delete what is held about them, it is your request to answer. PIPEDA gives you thirty days. We will help you meet that.
Our commitment. If you forward us a request, we will respond to you with what we hold about that person, in a readable form, within ten business days. If you instruct us to correct or delete a record, we will do it within ten business days and confirm in writing. If an individual contacts us directly about information that belongs to your account, we will not action it ourselves — we will tell them to contact you and let you know it happened.
How this actually works today, without varnish. There is no self-service export and no automated request handling. It is a person doing database queries by hand. Three things follow:
What does work automatically. Every status email to an applicant carries a one-click link to remove themselves from your pool, which suppresses further contact and stops any further email. Every role-invitation email carries a one-click unsubscribe and a standard list-unsubscribe header. Growth Program emails carry an opt-out. Marketing emails carry an unsubscribe that our senders check before sending, and which fails closed — if the check cannot be completed, the email is not sent. All of these are suppression, not deletion. Nothing is erased by clicking them, and the pages say so.
Our commitment to you. If we become aware of a breach of security safeguards involving your people's information, we will notify your account owner without undue delay and in any event within 72 hours of becoming aware. The notice will say what happened, when, which categories of information and roughly how many individuals are affected, what we have done, and what we recommend you do. If we do not have all of that at 72 hours, we will send what we have and follow up.
We will not notify your employees or applicants ourselves unless you ask us to in writing, or the law requires us to.
Your obligation, which we cannot discharge for you. Under PIPEDA section 10.1, if a breach involving information under your control creates a real risk of significant harm to an individual, you must report it to the Privacy Commissioner of Canada and notify the affected individuals, as soon as feasible. Under section 10.2 you must notify other organisations that may be able to reduce the risk. Under section 10.3 you must keep a record of every breach of security safeguards, whether or not it created a real risk of significant harm, and keep it for 24 months, and give it to the Commissioner on request. Failing to report or to keep records is an offence under the Act.
We keep our own record of every breach on the same basis, for the same period, and we will give you a copy of the entry for any incident that touched your data.
If you are a provincially regulated employer in Alberta, Alberta PIPA imposes its own duty to notify the Alberta Commissioner. British Columbia's rules differ. Your counsel should confirm which regime applies to you before you rely on this paragraph. [[COUNSEL TO VERIFY THE PROVINCIAL BREACH DUTIES]]
There is no retention schedule. Nothing in Quadrant expires on its own. There is no scheduled job that deletes personal information on age, and none of the five scheduled jobs that do run deletes anything on a clock. Records stay until somebody removes them. We are telling you this rather than printing a retention table we do not honour.
Deletion today is operator-initiated and immediate. When your admin deletes a person, their assessments and their record are removed straight away, matched both by their record identifier and by the email captured at assessment time. Deleting a job removes the job, its target profile and its links, but keeps the people who applied. There is a merge tool for duplicates. Removing a team member offers two modes: archive, which removes their membership and their course state for your account and keeps the history, and delete, which removes their course progress, course state and certificates for your account, their record, their assessments, their membership, and their login if they belong to no other client.
What no code path deletes, and you should know it:
Commitment. We will agree a written retention schedule with you if you want one, and we will apply it by hand until it is automated. If you tell us your own schedule — for example, applicant records for one year after a role closes — say so in writing and we will run to it.
When your subscription ends, whichever comes first:
Two honest notes about the mechanics. There is a platform function that deletes a whole client account, guarded by typing the company name exactly. Whether every dependent record is removed with it depends on how the database is configured to cascade, which we have not verified — so the deletion above will be done record-set by record-set and confirmed, not by pressing one button and hoping. [[VERIFY CASCADE BEHAVIOUR — ROD]] And nothing in the product deletes files from storage, so file deletion at termination is a manual step until that is built.
Copies held by sub-processors follow their own deletion timelines. Email delivery records at our email provider and platform logs at our host are not under our direct control and will age out on their schedules, not ours.
You are accountable for information you transfer to us, so you are entitled to satisfy yourself that we handle it properly. This is written to be proportionate to what we are: one person, not an enterprise vendor with an audit team.
We do not have a SOC 2 report, a penetration test report or a third-party audit to hand you. When we do, this section will say so.
Everything below is unresolved. It is collected here so that nothing in this document quietly depends on a fact nobody has checked.
privacy@disc-quadrant.com and jobs@disc-quadrant.com are monitored mailboxes.People Purpose Corporation
7 Fox Run, Kleefeld MB, R0A 0V2, Canada
Rod Penner, rod@people-purpose.com
Privacy requests: privacy@disc-quadrant.com
See also: how the assessment works and how to use it responsibly, and the assessment privacy notice written for the individual taking it.