What Kriteia does with your applicants’ data, on your behalf.

The organisation that runs a selection program on Kriteia decides why its applicants’ data is collected and what is done with it, so it is the data fiduciary, in the words of India’s Digital Personal Data Protection Act, 2023. Raitakarya Technologies Pvt Ltd operates Kriteia and processes that data on the organisation’s behalf, so it is the data processor.

The Act lets a data fiduciary use a data processor only under a valid contract (section 8(2)). This draft is written to become that contract once a lawyer has reviewed it and both parties have signed it. Until then it binds nobody. It describes what the product does today, so that an organisation and its counsel can read it before anything is signed.

Raitakarya Technologies Pvt Ltd’s registered address, PAN and GSTIN are not printed yet. They are printed here when they exist, and until then this page prints no placeholder in their place.

The subject of the processing is selection: choosing applicants for the organisation’s program. Raitakarya Technologies Pvt Ltd processes the program’s personal data to collect applications through a Kriteia form, or from a CSV file, Typeform or Airtable the organisation imports or connects; to put each one into a single readable record; to read the text of PDFs uploaded through the form and transcribe a video from a direct link to the file; to produce an evidence-cited first pass by two AI readers from different model families, and an AI check of any eligibility conditions the program sets; to let the organisation’s judges score applications; to record each decision a person makes; to send each applicant a confirmation, and later the reason a person at the organisation releases; and to keep a hash-chained record of what was decided, and when.

The processing is partly automated. Storage, text extraction, transcription, the AI first pass, the drafting of letters and the sending of email are done by software. Every decision is made by a person, and every letter is released by one.

It lasts as long as the organisation runs programs on Kriteia, and then until the data is returned or erased (clause 13). Kriteia has no automatic retention period yet, so nothing is deleted on a schedule.

Applicants. Whatever the organisation’s form or import asks for, which usually includes a name, an email address, a phone number, an organisation or institution and teammates’ names; the answers; the files an applicant uploads and the links they give; the text Kriteia extracts from an uploaded PDF and the transcript of a linked video; the AI readers’ assessments; judges’ scores and notes; decisions; letters; and the network address a request to the public form or the status page comes from, which is used to limit abuse.

The organisation’s own people. For each owner, admin, viewer and judge: a name, the address they sign in with and how they sign in, their role, and every act the record attributes to their account. For a judge, also the scores and notes they write. For anyone invited, the address the invitation was sent to.

The organisation decides what its form or import asks for (clause 04).

The organisation has a lawful basis under the Act, and has given the notice the Act requires, for every applicant whose data it instructs Kriteia to process, however the application arrives: through a Kriteia form, or in a CSV file, from Typeform or from Airtable. Under the Act that basis is the applicant’s consent, given after a notice (sections 5 and 6), or one of the legitimate uses section 7 lists.

Through a Kriteia form. The form shows Kriteia’s notice and purpose statement above a consent checkbox. Consent is captured at the form and checked in the database, and a program that has not published a purpose statement cannot collect a submission through a Kriteia form. What the form asks, and the purpose it states, remain the organisation’s choices.

Through an import. An applicant who arrives in a CSV file, from Typeform or from Airtable never saw Kriteia’s notice. By instructing Kriteia to process an imported application, the organisation confirms that, before the import, the applicant was told their application would be read with AI assistance and decided by people, and that the organisation has a lawful basis under the Act for that processing, including the email described next. Kriteia does not yet ask for this confirmation at each import, and records none. Until it does, this clause is the only place the organisation gives it.

Kriteia sends a confirmation email, with a link to the applicant’s own status page, to every applicant whose application carries an email address, imported applicants included.

Applicants under eighteen. If a program accepts them, the Act requires the verifiable consent of a parent or lawful guardian before their data is processed (section 9(1)). Obtaining it is the organisation’s responsibility: a Kriteia form asks no age and collects no guardian’s consent.

Instructions. The organisation instructs Raitakarya Technologies Pvt Ltd by what it does in the product, such as publishing a form, importing or connecting a source, deciding and releasing letters, and in writing. It answers its applicants’ requests under the Act, as clause 09 describes.

Raitakarya Technologies Pvt Ltd processes the organisation’s data only on its instructions, and only for the purpose in clause 02. If an instruction cannot be carried out with the product as built, Raitakarya Technologies Pvt Ltd says so rather than appearing to carry it out. An erasure request is the case that arises today (clause 10).

Any other use of the data needs the organisation’s separate written agreement, and this draft grants none. That includes the calibration study the terms describe for a first design partner.

Access to the production systems, meaning the database console, the stored files and each provider’s account, is limited to the people who run the service, and they keep the organisation’s data confidential. Production credentials are kept in the hosting provider’s settings, never in the code, and a change to the production database is applied by a person.

Raitakarya Technologies Pvt Ltd uses the sub-processors in clause 07 and no others, and tells the organisation before a new one receives its data. It helps the organisation answer its applicants (clause 09) and handle a breach (clause 11).

• Application data is stored in Postgres in Supabase’s Mumbai region (ap-south-1).
• Every table has row-level security, scoped to the organisation, so one organisation’s applications cannot be reached from another’s session.
• The database’s service-role key is not in the application’s environment at all. An upload is made with a token that lasts 120 seconds, for a role that can only add a file to one organisation’s folder; the upload route signs it with the project’s signing secret, the one secret of that kind the request path holds. The background pipeline connects to the database as a role that cannot bypass row-level security.
• Before either AI reader sees an application, identity is taken out of the copy it is shown: the applicant’s and teammates’ names, their organisation or institution, the program’s configured gender terms, and email, phone and URL handles. The stored record is not masked.
• A decision cannot be recorded without the identity of a signed-in person, taken from their session and never supplied by a caller. Revoked database grants, a fail-closed trigger and table ownership enforce it.
• Every decision, cut-line move, published rubric version, AI assessment and letter release is added to a SHA-256 hash chain through a single writer. Nothing on that record is updated or deleted, and it holds identifiers and hashes, never an answer, a name or an address.
• A Typeform or Airtable token the organisation connects is kept in Supabase Vault, and no screen can read it back.

Not in place: a SOC 2 report or an ISO certification, neither of which is in progress, and an error-monitoring service, which is not installed yet.

This list is read from the code that runs today. A provider is on it only if Kriteia’s code sends it personal data.

• Supabase holds the database, member sign-in and the stored files: everything clause 03 lists.
• Vercel hosts the web application and runs its server code, including each background step. Every page request, form submission and import passes through it; a file an applicant uploads goes straight to storage instead.
• Inngest runs the background pipeline. It schedules each step and stores what each step returns, which includes application content as it is processed, such as imported rows and extracted text; the applicant’s name, email address and status-page link when a confirmation is sent; and a letter and its address when it is sent.
• Anthropic provides the model behind the first AI reader and the program-setup draft. It receives an application’s text with identity taken out, and the description an organiser writes when they ask for a setup draft.
• OpenAI provides the models behind the second AI reader and the eligibility check. It receives an application’s text with identity taken out.
• Google provides, through the Gemini API, the model that drafts each letter. It receives the applicant’s name, the decision, the scored criteria and the passages of the application the letter cites, with other people’s names and contact details taken out.
• Deepgram transcribes a video an applicant links to directly. It receives the link, fetches the file and returns a transcript.
• Resend sends email: an applicant’s confirmation, with their name, address, status-page link and the names of their files; their letter; invitations to the organisation’s members; and alerts and daily summaries of the record, which carry no applicant’s name, address or answers.
• Langfuse records each AI call for monitoring: identifiers, the model, token counts, timing and the outcome, and Kriteia’s own prompt templates. It receives no application text and no identity.

Not on this list. The Vercel AI Gateway is configured for three AI roles that nothing calls yet, so no data reaches it. Sentry and PostHog are chosen and not installed. Typeform and Airtable are the organisation’s own services: Kriteia reads from them with the organisation’s credential, on its instruction. No payment provider receives applicant data.

What each one keeps. How long a provider keeps what it receives, and whether it may use it to improve its own models, is set by that provider’s terms for Raitakarya Technologies Pvt Ltd’s account. This draft has not checked those terms for every provider. No AI call is made with a zero-data-retention setting today, and the transcription request to Deepgram sets no opt-out from model improvement.

Before a new provider receives the organisation’s data, Raitakarya Technologies Pvt Ltd adds it to this list and tells the organisation.

The database is in Supabase’s Mumbai region. The other providers in clause 07 may process data outside India: this draft has not verified the region each one uses for Raitakarya Technologies Pvt Ltd’s account. The code sets no region for Vercel’s server functions, so they run wherever the Vercel project is set to run them.

The Act lets the Central Government restrict the transfer of personal data to a country or territory it notifies (section 16(1)). Whether any such notification reaches a provider on this list is for counsel to confirm.

Under the Act an applicant may ask the data fiduciary for a summary of their data and of who it was shared with, for its correction or erasure, and for a grievance to be answered (sections 11 to 13). Those requests go to the organisation, and its applicants are told so: a Kriteia form and the applicant’s status page both say to write to the organisation running the program.

Raitakarya Technologies Pvt Ltd helps the organisation answer them. Today that help is given by hand: the organisation’s owners and admins can read every application in the product, but there is no export of one applicant’s data and no erasure tool. A request that reaches Raitakarya Technologies Pvt Ltd directly is passed to the organisation, and acted on only on its instruction.

If an applicant withdraws consent, the Act requires the organisation to stop, and to have its data processor stop, processing their data within a reasonable time, unless a law requires or authorises it (section 6(6)). Kriteia has no control that stops the processing of one application; clause 10 says what can be done today.

Kriteia has no erasure tool and no automatic retention period yet. Nothing is deleted on a schedule, and an erasure request cannot yet be carried out inside the product.

What can be done today, on the organisation’s instruction: the files an applicant uploaded can be deleted from storage by Raitakarya Technologies Pvt Ltd, by hand; and the organisation can take its judges off the application, so that they can no longer read it. What cannot be done yet: removing the applicant’s answers and contact details, the text extracted from their files, the AI readers’ assessments, judges’ notes or a letter. Raitakarya Technologies Pvt Ltd handles these requests with an internal operator procedure that records what was done and what could not be.

The record of what was decided is never updated or deleted, and it holds identifiers and hashes, never an answer, a name or an address. Deleting an applicant’s files leaves it verifiable.

The Act requires a data fiduciary to erase personal data once consent is withdrawn or the purpose is no longer served, unless a law requires it to be kept, and to have its data processor erase what it was given (section 8(7)); and to erase on an applicant’s request on the same terms (section 12(3)). Until the erasure tool exists, Raitakarya Technologies Pvt Ltd cannot carry that out in full for the data held in the product, and says so here rather than in the middle of a request.

In the Act’s words, a personal data breach is any unauthorised processing of personal data, or its accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, that compromises its confidentiality, integrity or availability (section 2(u)).

If Raitakarya Technologies Pvt Ltd becomes aware of one affecting the organisation’s data, it tells the organisation without delay: what happened, which data and which applicants it affects as far as is known, what has been done about it, and who to contact. It keeps the organisation informed as it learns more.

That is so the organisation can meet its own duty to inform the Data Protection Board of India and each affected applicant (section 8(6)). Rule 7 of the Digital Personal Data Protection Rules, 2025 sets what that intimation contains and when it is due. This draft commits to telling the organisation without delay, and to no number of hours; the number is left to counsel.

No error-monitoring service is installed yet, so Raitakarya Technologies Pvt Ltd learns of a problem from its own logs and alerts, from a provider’s notice, or from a report.

Raitakarya Technologies Pvt Ltd answers the organisation’s written questions about the processing, and points it to the documents that describe it: this agreement, the privacy page, the terms and the methodology page.

The organisation can check its own program’s record: its owners, admins and viewers see on the program’s record page whether the record verifies, and an owner or admin can export it.

There is no SOC 2 report and no ISO certification, and neither is in progress. How, and how often, the organisation or an auditor it appoints may inspect the processing is left to counsel (clause 14).

The Act requires the organisation, once the purpose is no longer served, to have its data processor erase the data it was given, unless a law requires it to be kept (section 8(7)).

Today the product can export one thing: a program’s record, which an owner or admin can download. It has no export of the applications themselves and no erasure tool. Until both exist, how the data is returned and deleted at the end is settled in writing with the organisation, and this draft promises neither a format nor a date.

A lawyer’s review. This draft was written in-house from the code. When counsel has reviewed it, this page is replaced rather than amended, and the draft marker comes off.

A way to sign it. Nothing in the product lets an organisation accept or sign this agreement, and nobody has signed it.

The clauses a lawyer settles. Limitation of liability, indemnity, governing law, jurisdiction, dispute resolution, term and termination, the notice period and the right to object before a new sub-processor, audit rights, the addresses for notices, and the number of hours within which a breach is reported. Plausible boilerplate in their place would be text no document supports.

Questions left for counsel. Whether each provider’s own terms are adequate for the processing in clause 07, and where each one processes data. The wording of the confirmation an organisation gives for imported applicants, which Kriteia does not yet ask for at each import. And one description of the parties for both documents: the privacy page names Raitakarya Technologies Pvt Ltd as the data fiduciary for the processing it describes, and this draft names the organisation.

The registered details. The registered address, PAN and GSTIN named in clause 01, which are printed there when they exist.