Privacy notice (review draft)

The local engine does not imply memory upload; optional account, site, purchase, and support processing require explicit production disclosures.

Download the plain-text source.

KALEIDOSCOPE PRIVACY NOTICE
REVIEWED DRAFT - NOT YET IN FORCE

Draft of 23 August 2026

STATUS OF THIS DOCUMENT

This is a complete draft. It is not yet in force.

It has been reviewed by legal counsel for Kleos Research Private Limited, which
has not yet adopted it. It is published so that it can be read further before
adoption.

It describes what the product does today, at an alpha stage, and it is written
against Indian law: the Digital Personal Data Protection Act, 2023 and the
Digital Personal Data Protection Rules, 2025. Section 13 sets out which of
those obligations are in force now and which arrive later, with the
commencement dates.

One thing to be clear about, since "not in force" can be read too widely. Some
of what this notice describes binds us whether or not this draft is adopted:
the Information Technology Act, 2000 and the rules made under it apply to us
today, and so do the CERT-In directions described in sections 6.4 and 11. The
commitments this notice makes on top of those — the response periods in
section 9, the retention periods in section 7, and the backup window — are
ours to give, and they do not bind us until we adopt this notice.


1. WHO WE ARE, AND WHAT WE ARE ACCOUNTABLE FOR

Kleos Research Private Limited ("Kleos Research", "we", "us") is a private
limited company incorporated in India and registered in Delhi.

    Kleos Research Private Limited
    Email: contact@kleosresearch.xyz

Our full entity particulars, including our registered office address and our
Corporate Identity Number, are available on request at that address, and we
undertake to supply them to anyone who asks.

This notice covers two things: the Kaleidoscope software, and the
documentation website at memory.kleosresearch.xyz.

1.1 The line that matters most in this document

Kaleidoscope has two kinds of data in it, and we stand in a completely
different position to each.

  We are the Data Fiduciary for the account and device metadata whose purpose
  and means of processing we decide: the details you give us to get an alpha
  key, the small amount of information our validation service receives when
  your key is checked, and what you send us in support and security
  correspondence. Section 3 itemises all of it.

  We are NOT the Data Fiduciary for the contents of your local memory store —
  your vault. We are not a Data Processor of it either, because we do not
  process it on anyone's behalf: we never receive it at all. It is created on
  your hardware, at a path you choose, and it stays there. We do not decide
  the purpose or the means of processing it, we cannot read it, we cannot
  correct it, and we cannot delete it. If personal data of other people ends
  up in your vault, you are the Data Fiduciary for it and the accountability
  is yours, not ours, and this notice does not cover it.

That division is not a disclaimer bolted onto a hosted service. It is how the
product is built, and section 2 describes the mechanism.

"Data Fiduciary" is the term the Digital Personal Data Protection Act, 2023
uses for the organisation that decides why and how personal data is processed
and is accountable for it. "Data Processor" is the term for someone who
processes personal data on a Data Fiduciary's behalf. "Data Principal" is the
term for the individual the data is about. If we process your personal data
under section 3, you are the Data Principal and we are the Data Fiduciary.

1.2 Contact

For everything in this notice — questions about how we handle personal data,
requests to exercise your rights, and grievances — write to:

    contact@kleosresearch.xyz

That address is monitored and reaches a person who can answer questions about
our processing of personal data and who handles grievances. Section 8(9) of
the Act and Rule 9 of the Rules require us to publish that contact; this is
it. If we ever appoint a Data Protection Officer, we will publish their
business contact here in the same way.

1.3 Languages

This notice is available in English. We will provide it, and any consent
request we make, in any of the 22 languages listed in the Eighth Schedule to
the Constitution of India on request at the address above. That is the choice
section 5(3) of the Act gives you.


2. WHAT KALEIDOSCOPE IS, AND WHERE YOUR DATA SITS

2.1 Kaleidoscope is a memory system for AI agent tools. It runs on your own
machine.

2.2 Your memory store — the vault — is a set of files at a path you choose, on
hardware you control. Everything the product is for lives there:

  - the text of every memory you write, stored as ordinary markdown files, one
    per version;
  - an append-only journal of every event in the store, stored as ordinary
    line-delimited JSON;
  - a database file holding the derived indexes, the identity and ordering of
    records, the graph, and the search structures;
  - an exposure record for each ranked search — each search you run by query
    text — which includes the query text and the context that was served in
    answer to it. A read addressed to a single memory by its identifier is not
    a ranked search and writes no such record; and
  - the identifiers that address all of the above.

2.3 None of that is sent to us. We do not receive it, we do not hold it, we
cannot read it, and we cannot delete it. There is no hosted memory service. If
we ever build one it will need a separate agreement and a deliberate act by
you.

2.4 This is a property of how the product is built and not only a promise in a
document. The engine that holds your memory contains no network code at all,
and an automated build check refuses to accept any network client added to it.
The only network call the product causes is the entitlement check described in
section 3.2, and it is made by a separate helper program, not by the engine.

The engine starts that helper with no shell, a fixed argument list, its input
and output discarded, and the environment cleared and then set back to exactly
three values: the address of our validation service, which the engine
overwrites rather than inherits so that a variable set in your shell cannot
redirect the call; the directory the engine itself resolved for the cached
verdict; and your alpha key, which the helper needs in order to authenticate
and which is passed only if the engine had it in its own environment. Nothing
else from your shell, your agent, your editor, or your vault reaches it.

2.5 Because your vault is on your machine, you control it and you are
responsible for it. By default its contents are stored in plain text and are
protected by your operating system's file permissions and by nothing we add.
Encryption at rest is available on macOS, is not the default, and is switched
on by an explicit command; while an encrypted vault is mounted its contents
are readable by anything running as your user, so it protects the vault when
it is closed rather than while you are using it. Backing the vault up,
limiting who can read it, and deleting it are your operations, not ours.

2.6 Two things the product writes are deliberately outside the vault. Your
local profiles, which record vault paths and workspace, principal and journal
identifiers, and the cached entitlement verdict described in section 3.2, both
live in your operating system's per-user application configuration location,
readable only by your own user account. Neither contains memory text.


3. THE PERSONAL DATA WE ACTUALLY PROCESS

This section is the itemised description of the personal data we process, and
of the purpose each item is processed for, that Rule 3 of the Rules requires.
It is short because the product does very little that involves us.

Two notes on form, so that it is clear what this section is and is not. Rule 3
requires that description to be given independently of any other information,
so we also publish this section on its own at

    https://memory.kleosresearch.xyz/docs/legal/privacy-notice/

and the rest of this notice is context around it rather than part of it. And
where we ask you for consent, the request itself will carry this itemisation
and the link above, rather than pointing at a notice you have to go and find.

3.1 Getting you an alpha key

  What we process: your name, your email address, and anything else you choose
  to tell us when you ask for access or when we invite you. Our record of
  which key we issued to you, and when.

  Where our signup process asks you to identify the business you act for and
  to confirm your authority to act for it, we process that too. It is listed
  here because our terms are written on the footing that we collect it. If
  signup does not ask for it, we do not have it.

  Why: to decide whether to give you alpha access, to issue your key, to
  contact you about the alpha, and to revoke access when the alpha ends or if
  the key is misused.

  Basis: your consent, which you give by asking us for access. Where you gave
  us the information voluntarily for this purpose and have not indicated that
  you object to its use for it, section 7(a) of the Act — the legitimate use
  for voluntarily provided data — also applies.

3.2 Checking that a key is still valid

  What happens: a small cached file on your machine records the last answer we
  gave about your key. It is written inside your operating system's own
  application-configuration location — deliberately not inside your vault —
  and the product refuses to use it unless its file permissions make it
  readable only by your own user account. When that file is stale, a separate
  helper program refreshes it by making one request to our validation service
  over an encrypted connection.

  What that request contains: your alpha key, presented as an authorisation
  credential in the request header; and a body of exactly two fields — the
  operating system family the program is running on, which can only be
  "macos", "windows", or "linux", and the version number of the program making
  the call. That is the whole of it. There is no code path in the program that
  can add a third field: the body is built from a two-field structure with
  nothing else in it.

  What it does not contain: no memory content, no searches, no prompts, no
  results, no file names or paths, no vault, workspace, principal, or journal
  identifiers, no hardware or device fingerprint, no advertising identifier,
  and nothing from your agent or your editor. There is no device identifier of
  any kind in the request. "Device metadata", for us, means the operating
  system family and the version number, and nothing more.

  The key itself is personal data, and we treat it that way throughout this
  notice. An alpha key is not a name, but it is tied to the person or business
  we issued it to, and it recurs across every check made from your
  installation, so it is capable of identifying you. It is disclosed here and
  in section 6 on that footing.

  What we necessarily observe as well: as with any request to any server on
  the internet, our service sees the network address the request came from,
  the time it arrived, and ordinary connection metadata. We are saying so
  because it is true, not because we want it. An IP address can identify a
  person, so we treat it as personal data.

  What we store: a record that a key was checked, when, and what we answered.
  We will store a one-way cryptographic digest of the key rather than keeping
  a usable copy of it beside every event, and our service will reject a
  request whose body carries any field other than the two above. Those two are
  commitments about how we run our own service. They are not things you can
  verify from the software on your machine, and we would rather say so than
  present them as if you could.

  What is cached on your machine: our signed answer, a one-way digest of your
  key, the identifier we assigned to your key, and its expiry date. Not the
  key itself.

  How often: about once a day per installation in ordinary operation. Our
  service tells your installation how long to treat an answer as current and
  how long it may keep working if we cannot be reached; your installation will
  not accept more than 24 hours and 7 days whatever we send. Those ceilings
  are also the outer limit on how long a revoked key can keep working: 8 days.
  While an answer is stale, denied, or absent the helper may run more often —
  at most once every fifteen minutes, and without that throttle on the first
  check after a key is issued or changed. We are disclosing the failure-state
  rate because how often we hear from your installation is a processing fact,
  not an implementation detail.

  Why: to make revocation possible, to see whether a key is being shared, and
  to know roughly which platforms and versions are in use so that we can
  support them.

  Basis: your consent, which you give when you ask us for a key and install
  the software knowing that it checks. If you withdraw that consent we stop
  the processing and your alpha access ends with it — section 8 explains why
  and what it means. We are naming one basis rather than two: a purpose held
  up by consent and by something else as well is a purpose withdrawal does not
  actually stop, and that would make the right in section 6(4) of the Act
  worth less than it says.

3.3 Support

  Support runs through issues on our source repository, and by email to
  contact@kleosresearch.xyz.

  What we process: your account name on the repository, or your email address;
  and whatever you put in the issue or the message, including any diagnostic
  output you attach.

  Please do not send us credentials, private keys, memory content, searches,
  or private file paths. Redact your diagnostics before you send them. If you
  send us something you should not have, tell us and we will delete it.

  Why: to answer you.

  Basis: your consent, given by contacting us.

  Note: the repository is hosted by a third party who processes your data
  under its own notice and its own terms with you. We do not control that.

3.4 Security reports

  What we process: the contact details you give us, and the content of your
  report. See our security policy for what to send and what not to.

  Why: to investigate, to fix, and where you want it, to credit you.

  Basis: your consent, given by sending us the report. Separately, where an
  incident is one the CERT-In directions described in section 11 require us to
  report, we process and disclose what we must in order to comply with that
  law. That disclosure is required of us by statute; it is not something we do
  on the strength of your consent, and withdrawing consent does not stop it.

3.5 The documentation website

  This notice covers the website as well as the software, so here is what a
  visit to it involves.

  How it is served: the site is a set of static files served by GitHub Pages.
  GitHub keeps ordinary delivery and security logs, which include network
  addresses and request metadata, under its own terms.

  The one third-party request: the typefaces are fetched from Google Fonts, at
  fonts.googleapis.com and fonts.gstatic.com. Google therefore receives the
  request metadata a font fetch carries, including your IP address, under
  Google's own terms. There is no other third-party request. No external
  scripts, images, frames, or trackers are loaded, and the only other network
  request the site makes is to itself, to fetch a page you are likely to click
  next.

  Cookies: we set none.

  Browser storage: the site stores two things in your own browser. Your
  light-or-dark theme choice is kept in local storage, which persists until
  you clear it. The state of the navigation sidebar — which groups you left
  open, where you had scrolled, and a short check value the site uses to tell
  whether the navigation has changed since — is kept in session storage, which
  your browser discards when you close the tab. Both are functional, both stay
  in your browser, and neither is sent to us or to anyone else. An older
  version of the privacy page on this site said there was no browser storage
  at all. That was wrong, and this is the correction.

  What we do not do: we run no analytics, we set no advertising or tracking
  cookies, we do not build profiles of visitors, and nothing on the site reads
  a vault, a profile, or anything else on your machine.

3.6 What there is not

  There is no sign-in. There are no user accounts, no passwords, and no social
  or identity-provider login. No account service is running. Account features
  have been specified but not deployed, and the commands that would use them
  refuse and report that no provider is configured. If sign-in is ever
  switched on, this notice will be updated before it is, and the new
  processing will be described here.

  There are no payments, so we hold no payment or billing data.

  There is no telemetry, no analytics, no usage reporting, and no crash
  reporting anywhere in the product. The entitlement check in section 3.2 is
  the only network call the product makes, and its contents are listed above.
  Nothing else reports anything to us, on any schedule, in any build.


4. WHAT WE DO NOT DO

  We do not sell personal data or share it for anyone's advertising.
  We do not build profiles of you.
  We do not use your memory content, searches, prompts, or results to train
    any model. We could not: we never receive them.
  We do not track you across websites.


5. WHO ELSE SEES IT

We share personal data only with:

  (a) service providers who host our website, our validation service, our
      source repository, and our email, acting on our instructions and under
      contract;

  (b) professional advisers under a duty of confidence;

  (c) authorities, where the law requires it or where it is necessary to
      establish, exercise, or defend legal claims — including a report to the
      Indian Computer Emergency Response Team where section 11 requires one;
      and

  (d) a buyer or successor, if our business or the relevant part of it is sold
      or reorganised, subject to the same protections.

Section 11 of the Act gives you the right to be told who we have shared your
personal data with and what we shared. We will give you both: the identity of
each recipient, and a description of the personal data shared with them. We
will also name our service providers, and say which country each processes in,
to anyone who asks at contact@kleosresearch.xyz.


6. WHERE THIS DATA IS PROCESSED, AND CROSS-BORDER TRANSFERS

This section has two halves and both matter.

6.1 Your vault does not cross a border, because it does not move at all. Its
contents stay on the machine you put them on. Nothing in this section applies
to them, and using Kaleidoscope does not cause a cross-border transfer of your
memory content.

6.2 The account and device metadata in section 3 is different, and some of it
is processed outside India. Your alpha key is part of this half, not the first
one: it is linked to you, it travels with every validation request, and it is
handled wherever that request is handled.

  The documentation website is served by GitHub Pages, operated by a company
  established in the United States, from a global content delivery network.
  Typeface requests go to Google, also established in the United States. Both
  therefore see the request metadata described in section 3.5, including your
  IP address, wherever you are.

  Our source repository, where support issues are handled, is hosted by GitHub
  on the same basis.

  Our validation service, and the records described in section 3.2, run on
  infrastructure supplied by a third-party cloud provider, which may be
  located outside India. We will name that provider, and the country its
  infrastructure processes in, to anyone who asks at contact@kleosresearch.xyz
  — that is an undertaking to answer, not an invitation to write in — and we
  will name it in this notice before Kaleidoscope is generally available. We
  would rather name it here now. We have not, because the provider is not yet
  fixed, and naming one we then changed would be worse than saying so.

6.3 The legal position. Under section 16 of the Act and Rule 15 of the Rules,
an Indian Data Fiduciary may transfer personal data to any country except one
the Central Government restricts by notification. India works from a list of
restricted countries, not a list of approved ones, and no restriction has been
notified. We will comply with any that is, and we will update this notice if
we have to change providers because of one.

6.4 One localisation requirement already applies to us, and it is not in the
Act. The directions issued by the Indian Computer Emergency Response Team
(CERT-In) on 28 April 2022, under section 70B(6) of the Information Technology
Act, 2000, require an Indian body corporate to enable logs of all its ICT
systems, to maintain them securely for a rolling period of 180 days, and to
maintain them within Indian jurisdiction. That is in force now, it is
independent of the Act's commencement timetable, and section 7 reflects it.

Where any other sectoral regulator imposes its own localisation requirement,
that requirement applies in addition. None other currently applies to us.


7. HOW LONG WE KEEP IT

The rule we work to is the one section 8(7) of the Act sets: we erase personal
data, and cause our processors to erase it, as soon as you withdraw your
consent or the purpose we collected it for is no longer being served,
whichever is earlier — unless a law requires us to keep it. The periods below
are the outer limits we work within, not licences to hold data for that long.

  Alpha access records: while your key is live. After the alpha ends or your
    key is revoked, the purpose is spent and we erase them, except where we
    must keep a record to answer a claim that is live or reasonably in
    prospect, and no longer than 12 months in any event.

  Key validation events: 12 months. See the note below; this period is set by
    the log retention rules, not chosen by us.

  Support correspondence and issues: until the matter is closed and the
    purpose is spent, and no longer than 24 months after that.

  Security reports: 36 months after the matter is closed. We keep these longer
    because we may be required to show what we knew and when.

  Website and service logs: 12 months, except where an entry is retained for
    an active security investigation.

    Two floors set that figure and neither of them is ours to choose. The
    CERT-In directions described in section 6.4 require a rolling 180 days,
    within Indian jurisdiction, now. From 13 May 2027, Rule 6(e) of the Rules
    will require the access logs a Data Fiduciary keeps under Rule 6(c) — and
    the personal data in them — to be retained for one year unless another law
    requires otherwise. We have set one period that satisfies both rather than
    a shorter one we would have to lengthen. It is longer than we would
    otherwise choose, and we are saying why rather than presenting it as our
    own preference.

Where a law requires us to keep something for longer, we keep it for as long
as that law requires and no longer. Backups age out on their own cycle, which
is no longer than 35 days after deletion from the live system.

Your vault is not on this list. It is on your machine, we never receive it,
and its lifetime is entirely yours.


8. YOUR RIGHTS AS A DATA PRINCIPAL

Under the Act you have the following rights over the personal data described
in section 3.

How to use them: write to contact@kleosresearch.xyz, say which right you are
using, and give us the email address you gave us when you asked for a key.
That address is the identifier we hold, and it is what lets us find your
record. We may need to check who you are before we act, and we will only ask
for what we need to do that. There is no charge, and there is no form to fill
in.

Rule 14 of the Rules requires a Data Fiduciary to publish the means of making
such a request and the particulars needed to identify the person making it.
The paragraph above is that publication.

  Right to access information (section 11). You can ask for a summary of the
  personal data we process about you and what we are doing with it, and for
  the identities of everyone we have shared it with together with a
  description of what we shared.

  Right to correction and erasure (section 12). You can ask us to correct data
  that is wrong, complete data that is incomplete, update it, or erase it. We
  will erase it unless keeping it is required by law or is necessary for the
  purpose you gave it for.

  Right to withdraw consent (section 6(4)). Where we rely on your consent, you
  can withdraw it at any time, by writing one line to the address above — the
  same address, and no more effort, than it took to give consent in the first
  place. Withdrawing does not undo processing that already happened lawfully.
  It does have a consequence you should know about: your alpha key exists
  because we hold a record of it and check it, so withdrawing consent to that
  processing means we end your alpha access. Your vault stays where it is; it
  is not ours to withdraw.

  Right to grievance redressal (section 13). You can complain to us about
  anything in this notice or anything we have done with your data, whether or
  not you have used another right first. Section 9 explains how.

  Right to nominate (section 14). You can nominate another person to exercise
  your rights on your behalf if you die or become incapable of acting. Tell us
  at the address above.

  Right to complain to the Data Protection Board of India. If we do not deal
  with your grievance properly, you can take it to the Board. Section 13(3) of
  the Act makes exhausting our own grievance process a condition of
  approaching the Board, so raise it with us first and give us the time in
  section 9 to answer. After that, a complaint is made to the Board in the
  manner the Board itself prescribes: it is designed to be made online, at the
  address the Board publishes, and it must set out who you are, what happened,
  what you asked us for and when, and what we said. If you tell us you intend
  to complain, we will give you our correspondence with you in a form you can
  attach, and we will tell you where the Board's current filing address is.

One limit, stated plainly: these rights reach the data in section 3 and
nothing else. We cannot act on a request about the contents of your vault,
because we do not have them. You do not need us for that data and you do not
need our permission: the memories are ordinary markdown files in a directory
on your own disk, with the event journal beside them as line-delimited JSON,
and you can read them, copy them, back them up, or delete them with your own
tools, at any time, whether or not your alpha key is valid and whether or not
we still exist. What needs the software is reconstructing the derived indexes,
not reading your own text.

You also have duties under section 15 of the Act, including not to make a
false or frivolous complaint and not to give false particulars when exercising
a right.


9. GRIEVANCES

Write to contact@kleosresearch.xyz with "Grievance" in the subject line.

We will acknowledge you within 7 days and give you our answer within one month
of receiving the grievance. If we need longer, we will tell you why and when
to expect an answer.

We are choosing one month. The outer limits the law sets are these: Rule 14 of
the Rules requires a response within a reasonable period not exceeding 90
days, and Rule 5(9) of the Information Technology (Reasonable Security
Practices and Procedures and Sensitive Personal Data or Information) Rules,
2011, which binds us until it is repealed, requires redressal within one
month. We have taken the shorter of the two and applied it to everything.

If you are not satisfied, you can go to the Data Protection Board of India,
subject to section 13(3) of the Act as described in section 8.


10. CONSENT MANAGERS

The Act lets a Data Principal give, manage, review, and withdraw consent
through a Consent Manager — an independent entity registered with the Data
Protection Board that acts as a single point for doing so.

We do not currently use a Consent Manager. The Consent Manager provisions
commence on 13 November 2026. If we start using one, we will say so here and
you will be able to manage your consent through it. Until then, and after it,
writing to contact@kleosresearch.xyz works.


11. PERSONAL DATA BREACHES

If a personal data breach affects your personal data, we will tell you without
delay, in plain language, describing what happened, what it means for you,
what we have done about it, what you can do, and who to contact.

We will also tell the Data Protection Board of India without delay, and give
the Board a detailed report within 72 hours of becoming aware of the breach,
or within any longer period the Board allows on a written request. That is the
timing set by Rule 7 of the Rules.

There is a second clock, and it is much shorter. The CERT-In directions of
28 April 2022 require an Indian body corporate to report the cyber incidents
they list to the Indian Computer Emergency Response Team within 6 hours of
becoming aware of them. That obligation is in force now, it is not displaced
by the Act, and it can apply to an incident that is not a personal data breach
at all. Where both apply, we will meet both, and the CERT-In report will
usually be the first thing that happens.

Because your vault never leaves your machine, a breach of our systems cannot
expose your memory content. It could expose the categories of data listed in
section 3.


12. CHILDREN

Kaleidoscope is offered to businesses, for business purposes. It is not
offered to, or directed at, children.

Under Indian law a child is anyone under 18 — not 16, and not 13. We do not
process the personal data of a child. Section 9(1) of the Act requires
verifiable parental consent before a child's personal data may be processed at
all, and we have not built anything to obtain it, so a child's data is not
something we are equipped to hold lawfully. We do not do behavioural
monitoring or tracking of children, and we do not do targeted advertising at
all, let alone at children; section 9(3) of the Act prohibits both outright,
and parental consent would not make them permissible.

If you believe we hold a child's personal data, tell us at
contact@kleosresearch.xyz and we will delete it.


13. WHICH OBLIGATIONS APPLY NOW, AND WHICH APPLY LATER

The short answer first: until 13 May 2027 the older Information Technology Act
rules are the data protection law that applies to us, and this notice already
meets them. The rest of this section is why, and what changes when.

We are setting it out because it is easy to get wrong, and because a notice
that quietly implies the whole Act is already in force is inaccurate in a way
that favours us.

The Digital Personal Data Protection Act, 2023 is being brought into force in
stages by the commencement notification cited at the end of this notice. The
Rules were notified on 13 November 2025 and published in the Gazette the
following day; both dates appear in circulating summaries and they refer to
the same instrument.

  In force now: the definitions, and the provisions constituting the Data
  Protection Board of India and giving it its powers. Those provisions have
  been in force since 13 November 2025.

  From 13 November 2026: the Consent Manager provisions — registration of
  Consent Managers and their obligations.

  From 13 May 2027: the principal obligations — notice, consent, the duties of
  a Data Fiduciary, Data Principal rights, the Significant Data Fiduciary
  provisions, and the cross-border transfer provisions.

Until 13 May 2027, the operative data protection law for us is section 43A and
section 72A of the Information Technology Act, 2000 and the Information
Technology (Reasonable Security Practices and Procedures and Sensitive
Personal Data or Information) Rules, 2011. Those Rules require a body
corporate to publish a privacy policy, to name a grievance officer, and to
resolve grievances within one month. This notice is written to meet them now.
Section 43A is omitted by section 44(2) of the Act, and that sub-section is
itself one of the provisions that commences on 13 May 2027 — which is why
section 43A is still live today and this notice still answers to it. Section
72A is not repealed by the Act and continues after that date.

We have chosen to write this notice to the Digital Personal Data Protection
standard now rather than in 2027. The rights in section 8 and the grievance
process in section 9 are available to you today, whether or not the section of
the Act that will require them has commenced. If you exercise one of them now,
we will not tell you to come back in 2027.

13.1 Significant Data Fiduciary status

A Significant Data Fiduciary is not a category an organisation puts itself in
or takes itself out of. Under section 10 of the Act, the Central Government
designates a Data Fiduciary, or a class of them, as significant, having regard
to factors including the volume and sensitivity of the personal data
processed, the risk to the rights of Data Principals, the potential impact on
the sovereignty and integrity of India, the risk to electoral democracy, the
security of the State, and public order.

We have not been designated. No Significant Data Fiduciary obligation
therefore applies to us, and we do not claim to have carried out any
assessment that exempts us from one — that is not how the provision works, and
the provision has not commenced in any event. Designation is in our view
unlikely at the scale described in this notice, but that is an observation
about scale and not a determination we are entitled to make.

If we are ever designated, the additional duties — a Data Protection Officer
based in India who reports to the board, an independent data auditor, periodic
data protection impact assessments, and periodic audits — would apply, and we
would update this notice and tell alpha testers.


14. HOW WE PROTECT IT

We keep the amount of personal data we hold small, which is the most effective
protection available to us.

Rule 6 of the Rules sets out the safeguards a Data Fiduciary must have. Taking
them in the order the Rule lists them, and saying honestly which are in place
and which are undertakings for a service we have not finished building:

  (a) Protecting stored personal data. The alpha key is stored as a one-way
      digest rather than in a form we could reuse. Records at rest in our
      validation service will be encrypted. On your machine, the key file and
      the cached verdict are refused rather than used if their file
      permissions would let anyone else on the machine read them.

  (b) Controlling access. Access to our systems is limited to the people who
      need it, and it is removed when they no longer do.

  (c) Logs, and monitoring for unauthorised access. We keep access logs and
      review them. Section 7 says how long we keep them and why that period
      is not ours to choose.

  (d) Continuing to process if data is compromised. We keep backups, and the
      data we hold is small enough to restore quickly.

  (e) Retention of logs. See section 7.

  (f) Contracts with processors. Our service providers are engaged under
      contract, and those contracts carry the obligations this Rule requires.

  (g) Means of enforcement. This notice, and the contracts above.

Transport encryption protects the validation request in flight, and our
service will reject a request carrying any field other than the two in section
3.2. Items (a), (c), (d), (f) and the rejection rule are commitments about a
service we run and cannot be checked from the software on your machine. We
will have them in place before this notice is adopted.

No system is perfectly secure. Protect your own machines and your alpha key,
and report anything suspicious under our security policy.


15. CHANGES

If we change this notice materially we will say so on this page and, where the
change affects processing we do under your consent, we will tell you before it
takes effect. The date at the top shows when this version was written. We will
keep earlier versions available.

A change to this notice cannot authorise a new use of data we never had. Your
vault is not ours to reclassify.


16. CONTACT

    Kleos Research Private Limited
    A private limited company incorporated in India, registered in Delhi
    Email: contact@kleosresearch.xyz

Full entity particulars, including the registered office address and the
Corporate Identity Number, are available on request at that address, and we
undertake to supply them.

Data Protection Board of India — for complaints you have raised with us first
and are not satisfied about.


SOURCES RELIED ON

These are references for the reviewer. They are not terms of this notice.

  Digital Personal Data Protection Act, 2023 — commencement notification
  https://www.meity.gov.in/static/uploads/2025/11/c56ceae6c383460ca69577428d36828b.pdf

  Digital Personal Data Protection Act, 2023
  https://www.indiacode.nic.in/bitstream/123456789/20063/1/a2023-22.pdf

  Digital Personal Data Protection Rules, 2025
  https://www.dsci.in/files/content/documents/2025/Digital-Personal-Data-Protection-Rules-2025.pdf

  CERT-In directions under section 70B(6) of the Information Technology Act,
  2000, dated 28 April 2022
  https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf


END OF REVIEW DRAFT