Privacy policy

This policy explains the data what's true? stores, why it stores it, who receives it, and the choices you have. It covers the hosted public alpha at true.krnl.studio, which KRNL runs. KRNL is the studio behind krnl.studio.

what's true? keeps a product's public docs true. It reads the docs in your repository, notices when a merged pull request changes what a doc covers, checks public text before it ships, and holds a pull request until a person approves it.

There is no built-in AI

what's true? does not call an AI model and does not generate content. People, and the agents they choose to use, write the docs. what's true? checks the text, says which docs need review, and records who approved each change.

Signing in

You sign in with your KRNL account. KRNL accounts use WorkOS for sign-in. When you sign in, what's true? receives your account identifier, your email address and your name. Only a verified email address can sign in.

what's true? keeps a record of each sign-in: who you are, when you signed in, and a reference to your KRNL sign-in, so that signing out of what's true? ends that too. Your browser holds a random token in a cookie, and we store only a one-way hash of it. While you are signed in, what's true? checks with KRNL from time to time that your KRNL sign-in is still active.

What we store

For each workspace, what's true? stores:

• Workspaces and members. The workspace's name, and each member's name, email address, level and approve permissions. An invitation not yet taken up holds an email address, a name, the permissions offered and who sent it.
• Products. Each product's name and address, its settings, the repository and branch it reads, the KRNL OS project it is linked to, if any, and whether the repository's branch protection requires the what's true? status.
• Your docs. The docs on your default branch: their text, front matter, coverage and facts. what's true? reads them through the GitHub App, or from a manifest your CI uploads. Uploaded manifests are kept by commit.
• Pull requests. For pull requests to your default branch: the number, title, link, labels, commits and the names of the files they change. For merged pull requests, also the author's GitHub username.
• Reviews and stale records. The doc changes in each pull request, what the guard found, why a doc may be out of date, questions and answers, notes, and each decision with the name of the person who made it and when.
• Legal versions. Each published version of a legal doc: its text, effective date, the pull request that changed it, who approved it, whether the change was material, and any counsel review you record.
• Tokens. Each product token's name, scopes, a short prefix, who made it and when it was last used. We store a one-way hash of the token, not the token itself.
• Audit log. Who did what in the workspace, and when. It holds names, actions and identifiers, not tokens or secrets.

what's true? also stores:

• Consent records. When you create a workspace: your account identifier, your email address, the versions of the terms and of this policy that you accepted, and when.
• Sign-in records, as described above.
• GitHub App records. The installations of the what's true? GitHub App, with the account and repository names they cover, and the identifiers of the webhook deliveries GitHub sends, so that none is handled twice.
• Usage counts. Counts that keep the alpha's limits, such as how often a token is used. They are kept under one-way hashes, not under a token or an address.
• Work in progress. Tasks waiting to run, such as a status to post to GitHub or an event to send to KRNL OS.

what's true? reads the names of the files in your repository, and the text of only your docs and your what's true? config files. It does not store the rest of your code.

Cookies and browser storage

what's true? sets a cookie that keeps you signed in, and a short-lived cookie while you sign in. Your browser also remembers which workspace you opened last. what's true? sets no advertising or analytics cookies. The only script it loads from another site is Cloudflare's check on the form that creates a workspace.

How we use it

We use this data to:

• sign you in and keep you signed in;
• read and check your docs, notice when a merged pull request changes what a doc covers, and hold a pull request until a person approves it;
• keep people's names out of your public docs: the guard checks your docs for the names of the people in your workspace;
• show your workspace its docs, reviews, stale records and history;
• keep the alpha's limits and protect the service from misuse;
• find and fix faults.

We do not sell your data, and we do not use it for advertising. what's true? does not send email. An invitation waits in the workspace until the person signs in with that address.

Who can see it

People in your workspace see its records according to their level. Admins and owners also see its members, invitations and tokens. A product token sees only its own product, and no token can approve a change. Approval needs a signed-in person with the right approve permission.

KRNL may access records to run the service, to help you when you ask, and to investigate faults or misuse.

Who we share it with

• GitHub. Through the GitHub App you install, what's true? reads your repository as described above, and posts a commit status on your pull requests with a short summary and a link to the review in what's true?.
• KRNL OS. If you enable docs for a product from a KRNL OS project, KRNL OS holds a product token for it. KRNL OS can then read and work with that product's records for the people and agents in that project. It cannot approve anything. When a stale record opens, clears or is dismissed, what's true? sends KRNL OS an event so it can open or close an issue. The event names the product and the doc, and says why the doc may be out of date, including pull request titles, file names, labels and fact values. When a record opens, the event lists the email addresses of the members who may answer it. When a record closes, it says who closed it.
• Service providers. Vercel hosts what's true?, and Supabase hosts its database. KRNL accounts use WorkOS for sign-in. Cloudflare runs the check that you are a person when you create a workspace, and handles your network address and browser details to do it. They handle data to provide their services. Our hosting provider also handles your network address and browser details to deliver each page.
• The public. When a product publishes a legal doc through what's true?, the published versions of that doc, with their text and dates, are public, so the product's own site can show them. They do not say who approved them.
• When the law requires it. We may disclose data if the law requires us to.

Your data and your choices

Your organisation decides what goes into its workspace and its repositories, and who has access.

• Export. Workspace admins can download the workspace's records as JSON from its Members page: its members and invitations, products, token details, docs, facts, reviews, stale records, legal versions and audit log.
• Deletion. A workspace owner can delete the workspace. That removes its products and the records in it from the service's database. Admins can delete a product, revoke tokens and remove members. A person removed from a workspace loses access, but their name stays on the records of what they did, such as approvals and the audit log, so the history stays accurate.
• What deletion does not reach. Some records are not part of a workspace and stay after it is deleted: consent records, sign-in records until they expire, GitHub App installation and delivery records, and usage counts. Deleting a workspace does not remove commit statuses already on GitHub or issues already in KRNL OS. To stop what's true? reading a repository, uninstall the GitHub App on GitHub.
• Your account. The alpha has no self-service account deletion. To have your account records deleted, for help with an export, or with any privacy question, write to team@krnl.studio.

The alpha has no fixed retention periods. We keep a workspace's records while the workspace exists.

Security

Product tokens and browser sign-ins are stored as one-way hashes, and the service's own secrets stay on the server. Each action is checked against the caller's identity, workspace and level. No service can be fully secure, so do not put secrets in your docs or in text you check.

Changes to this policy

This policy is a legal doc in what's true? itself, so a merged pull request that changes the code it describes marks it for review. The date at the top of this page shows when this version took effect. When you create a workspace, what's true? records which version you accepted.

Contact

Write to team@krnl.studio with any question about this policy or your data.