# K2F — Frequently Asked Questions

## Table of contents

1. [First questions](#1-first-questions)
2. [The `.K2F` package](#2-the-k2f-package)
3. [Deterministic rendering](#3-deterministic-rendering)
4. [AI agents, skills, and editing](#4-ai-agents-skills-and-editing)
5. [Exports and delivery](#5-exports-and-delivery)
6. [Gallery and templates](#6-gallery-and-templates)
7. [Ecosystem and tooling](#7-ecosystem-and-tooling)
8. [Privacy, security, and data handling](#8-privacy-security-and-data-handling)
9. [Version control and collaboration](#9-version-control-and-collaboration)
10. [Comparisons with other formats and tools](#10-comparisons-with-other-formats-and-tools)
12. [Limits, roadmap, and trust](#12-limits-roadmap-and-trust)

---

## 1. First questions

### What is K2F in one sentence?

K2F is an **open document file format** (like PDF or DOCX) built for the AI era: you edit a **semantic JSON tree** and a **theme** inside a ZIP; a reference engine **compiles** that into a **render lock** so every K2F viewer shows the same pixels. You can export Word, PowerPoint, fillable PDF, IDML, Markdown, and images from that lock.

### Is K2F a SaaS, a library, or a file format?

All three, in layers:

- **File format** — Apache 2.0 spec and schemas; you can store `.K2F` files anywhere.
- **Reference engine and SDKs** — open source; published on PyPI (`pip install k2f`), npm (`@openk2f/k2f`), and crates.io (`cargo install k2f`).
- **k2f.dev services** — optional: Gallery, Playground, docs, and hosted viewer URLs. You do not need an account to download Gallery templates or use the agent skill workflow locally.

### Who is K2F for?

- Teams that want **AI agents** to create or update **polished, designed documents** without wrestling with OOXML or PDF coordinates.
- People who need **one semantic source** and multiple **delivery formats** (DOCX for legal, PPTX for slides-as-pages, PDF for signing, IDML for InDesign).
- Organizations that want **Git-friendly** document sources, node-level edits, and **deterministic review** in K2F viewers.
- Developers embedding documents via **CLI, Python/JS SDK, WASM, or MCP**.

K2F is designed to **work alongside** the tools teams already use — Office, InDesign, PDF readers, and design apps stay part of the workflow. It is strongest as an **agent-friendly source** and compile hub, not as a drop-in duplicate of every feature in desktop Office, InDesign, or casual design tools; see [Limits](#12-limits-roadmap-and-trust).

### What do I need installed?

Minimum for agent workflows:

```bash
pip install k2f    # CLI + Python SDK on PATH
```

Optional:

```bash
npx skills add suzheng/k2f --skill k2f   # Agent skill for Cursor, Claude Code, Codex, etc.
npm i @openk2f/k2f                                 # Only if you embed <k2f-viewer> in a web app
```

### How do I start in about 60 seconds?

**Path A — Gallery:** Browse [k2f.dev/gallery](https://k2f.dev/gallery), download a `.K2F` template (no login), open in [Playground](https://k2f.dev/playground) or unpack with `k2f unpack`.

**Path B — Agent:** Paste into your agent:

```text
Use the K2F skill to create a [describe what you want]. Install with npx skills add suzheng/k2f --skill k2f if needed.
```

The agent edits JSON under `source/`, runs pack/compile, and delivers a `.K2F` plus exports you ask for.

### Is K2F free? Do I need a paid plan or account?

The **format and reference engine** are open source (Apache 2.0). The **CLI/SDK** are free to install from public registries. **Gallery** templates are free to download without login. **k2f.dev** does not require an account for Gallery, docs, Playground browsing, or the agent skill workflow. Optional hosted features (share/publish links on k2f.dev) are convenience — not a metered “K2F cloud compile” product. For privacy and what touches servers, see [§8](#8-privacy-security-and-data-handling).

### How does K2F fit with Word, PowerPoint, InDesign, and PDF?

K2F is an **additional layer** in the stack — not a swap for the apps your organization already standardizes on.

| Role | How they fit together |
|------|------------------------|
| **Agent- and Git-friendly authoring** | When you want structured edits, `.K2F` semantic tree + theme is the editable source you compile from. |
| **Consistent review** | Playground, Desktop Reader, and Web Viewer paint the same lock; lock-based PDF is a common approval path. |
| **Desktop collaboration** | Export DOCX, PPTX, or IDML so colleagues work in familiar apps; **change content in K2F and re-export** — those files are delivery, not authoritative sources. |
| **Deck-native or whiteboard authoring** | **Paged documents are shipped today** (`canvas_mode: "paged"`); native slide and infinite canvas modes are on the roadmap. |

---

## 2. The `.K2F` package

### What is inside a `.K2F` file?

A `.K2F` file is a **ZIP package**. Typical layout:

| Path | Purpose |
|------|---------|
| `manifest.json` | Metadata: page size, margins, canvas mode, engine identity |
| `content/root.json` | **State A** — semantic content tree (what you edit) |
| `content/**/*.json` | Optional fragments included from the root |
| `styles/theme.json` | Roles, palette, typography — appearance without coordinates |
| `assets/fonts/`, `assets/images/`, `assets/data/` | Embedded resources |
| `/schema/` | Embedded JSON Schema for validation |
| `document.K2F.lock` | **State C** — compiled geometry and paint plan (after `compile`) |
| `changelog.json` | Optional edit history |
| `signatures/v1.json` | Optional Ed25519 signatures |

Everything needed to **interpret, compile, and render** the document canonically is in the package or version-bound in the manifest — not on a random CDN font URL.

### Why do you call the package “self-contained”?

- **Fonts** are embedded under `assets/fonts/`; canonical rendering does not depend on what is installed on the reviewer’s laptop.
- **Images and data** live under `assets/`; agents can swap datasets without breaking structure.
- **Schemas** ship inside the ZIP so validators and agents can self-check offline.
- After compile, the **lock** captures exact layout so viewers do not need to guess fonts or reflow text.

You can email one `.K2F` file, commit it to Git, or hand it to an agent — the recipient has the full story.

### Can I give a `.K2F` to a colleague or another AI agent?

**Yes.** That is a primary workflow.

1. They **unpack** (or use SDK/Playground) to reach `content/root.json` and `styles/theme.json`.
2. They change **meaning** (text, tables, structure) by stable node `id`, or adjust **theme** for a global restyle.
3. They **pack** and **compile** to refresh `document.K2F.lock`.
4. Viewers and exports use the new lock.

They should **not** hand-edit the lock file or treat an exported DOCX as the new source (`DOCX_IS_NOT_A_SOURCE`).

### What is the difference between what I edit and what viewers show?

- **State A (semantic tree)** — Mutable JSON: headings, paragraphs, tables, `form_field` nodes, roles, variants. **No physical coordinates** in the content layer.
- **State C (render lock)** — Immutable output of compile: glyph positions, boxes, draw order, `content_hash`, `appearance_hash`.

**Compile** runs when content or theme changes. **Open** in a viewer only **executes** the lock — it does not re-layout body copy. Edits to JSON are invisible in preview until you recompile.

### Do I need the internet to open or verify a file?

No, once tools are installed. The CLI, Desktop Reader (preview builds on [k2f.dev/download](https://k2f.dev/download)), and local WASM can open and export offline. Gallery fetch is optional; templates can be saved and reused locally.

### Is the source “just JSON”? Can I use Git?

Yes. Content and theme are JSON. The toolchain uses **canonical JSON** (stable key order, consistent spacing) so diffs highlight semantic changes. Stable hierarchical ids (e.g. `invoice.header`, `financials.q3_results.table_revenue`) make code review and agent patches readable compared to binary DOCX.

### Can I create and edit K2F files programmatically?

**Yes.** A `.K2F` file is a **ZIP**. Unpack it and the authoring surface is plain **JSON** under `content/` and `styles/theme.json` — any language can read, create, or patch those files.

Typical automation paths:

- **CLI** — `k2f unpack`, edit files, `k2f pack`, `k2f compile`, `k2f export-*`
- **Python** — `pip install k2f` (pack, compile, verify, exports)
- **JavaScript/TypeScript** — `npm i @openk2f/k2f` (WASM compile, viewer embed, exports)
- **Agents** — K2F skill + `pack_verify.py` loop

You do not need a GUI. For schema shapes and roles, see [docs](https://k2f.dev/docs) and the embedded `/schema/` in each package.

### Do I need the K2F engine to read a `.K2F` file?

**It depends what you mean by “read.”**

| Goal | Need the reference engine? |
|------|----------------------------|
| Read or edit **semantic JSON** (content + theme) | **No** — unzip the package; use Git, scripts, or any JSON tool |
| **Preview** the designed page or **export** PDF/DOCX/PPTX/IDML | **Yes** — compile (if needed) and run the CLI, SDK, Desktop Reader, or `<k2f-viewer>` |
| Paint an existing **`document.K2F.lock`** pixel-identically in a K2F viewer | **Yes** — viewers execute the lock; they do not re-typeset from JSON alone |

The format is open; the engine is the supported way to turn JSON + theme into layout and delivery formats.

---

## 3. Deterministic rendering

This section defines what we mean by “deterministic” — and what we **do not** mean.

### What does “deterministic rendering” mean for K2F?

Given the **same** `.K2F` package (content, theme, embedded fonts, manifest) and the **same pinned reference engine version**, the **canonical output is identical everywhere**:

- [Playground](https://k2f.dev/playground)
- Web Viewer (`<k2f-viewer>`)
- Desktop Reader
- Default **PDF export** drawn from the lock (customer delivery path)

Same document → same pixels on every device and every K2F-compatible app. That is the PDF-like consistency goal for **K2F-native** viewing and lock-based PDF.

### How does K2F handle fonts and rendering across different machines?

**Inside K2F (viewer, lock PDF, Playground):** Fonts live in the package under `assets/fonts/`. Canonical rendering uses those embedded files — not “whatever happens to be installed on the laptop.” That is why K2F preview is consistent across machines when you use the same lock and engine line.

**Exports to Word or PowerPoint:** DOCX and PPTX are **not** self-contained font carriers the way a `.K2F` ZIP is. Default Office exports draw the lock but **do not embed the full font set** the way K2F does. Word and PowerPoint substitute or metric-match fonts, so **line breaks and spacing can shift** — one of the main reasons Office exports are collaboration handoffs, not pixel-perfect clones of the K2F viewer.

**Export to IDML:** Default **IDML package export** includes a **`Document Fonts/`** folder with fonts used in the export, so InDesign handoff is closer to “bring your fonts with the file.” InDesign still has its own layout engine — **slight reflow remains possible**.

**PDF from the lock** is the usual approval and print path when you need output closest to what K2F showed.

### Are K2F viewers allowed to re-layout my document when I open it?

**No.** Viewers are **lock executors**: they paint `document.K2F.lock`. If you open a locked package, you see what was compiled — not a browser-dependent reflow of your JSON. When content changes, you **recompile** to produce a new lock.

### If I export to Word, PowerPoint, PDF, or IDML, is the layout identical to the K2F viewer?

**Not guaranteed — and that is expected.**

Exports are **one-way drawings of the published lock** into foreign formats. They are **not** a second canonical renderer:

| Export | Relationship to K2F viewer |
|--------|----------------------------|
| **PDF** (from lock) | Closest to pixel parity; primary print/approval path. Fillable fields use AcroForm unless `--flatten`. |
| **DOCX** | Editable Word drawing of the lock; **slight text reflow in Word is expected and allowed**. Not Word’s native flow model. |
| **PPTX** | Same class as DOCX — lock geometry mapped into slides; **slight reflow possible**. |
| **IDML** | Opens in InDesign with its own engine; fonts packaged in export folder when using default package export; **slight reflow possible**. |

Different file formats, font metrics, and app behavior mean **Word on macOS vs Windows**, **PowerPoint theme defaults**, or **InDesign version** can shift spacing, line breaks, or substitution. K2F does **not** promise that exported Office or IDML files are pixel-identical to the K2F viewer.

**Deterministic rendering applies to K2F execution of the lock** — not to “K2F → Word looks exactly like K2F everywhere forever.”

### Does “deterministic” mean exports never change between K2F versions?

Lock hashes and export bytes are tied to **engine version** (`engine_version` on the lock). Upgrading the CLI/SDK may require recompile. Exports always reflect **the lock that was published at compile time**, not live edits to JSON until you save and recompile.

---

## 4. AI agents, skills, and editing

### Why are PDF and DOCX bad *sources* for AI agents?

- **PDF** traps meaning in coordinates and opaque drawing operators — reliable structure extraction and safe edits are hard (`PDF_IS_NOT_A_SOURCE`).
- **DOCX** is a ZIP of intricate OOXML: styles, numbering, relationships, and split text runs. Naive “convert to Markdown and back” destroys formatting; whole-document regeneration breaks tables and numbering. Industry writeups call this the **Word last mile** problem for AI.

K2F gives agents a **small, semantic JSON dialect** (roles, ids, closed modifier types) instead of OOXML surgery.

### How does K2F reduce “the agent broke my layout”?

1. **Content / style separation** — Nodes carry `role` / `variant`; colors and font sizes live only in `theme.json`. Inline styles on nodes are invalid and fail compile.
2. **Stable ids** — Patch `invoice.details` without touching unrelated nodes.
3. **Engine-owned layout** — Agents describe *what* things are; the engine computes geometry on compile.
4. **Lock for preview** — Everyone reviews the same compiled output; no HTML/CSS reflow surprises in K2F viewers.

Restyling (“switch to a dark corporate palette”) means editing **theme**, then recompile — not nudging coordinates.

### What is the K2F skill and how do I use it?

The **K2F skill** is an installable instruction pack plus scripts and examples ([`skills/core/k2f`](https://github.com/suzheng/k2f/tree/main/skills/core/k2f) in the k2f repo). Install:

```bash
npx skills add suzheng/k2f --skill k2f
```

Then prompt:

```text
Use the K2F skill to create a [describe what you want].
```

The skill teaches the agent the edit loop: workspace layout, `pack_verify.py`, catalog examples, export references, and error codes — **without** needing this monorepo checkout.

### Which AI agents work with K2F?

Any agent that can run shell commands and use **Agent Skills** (or follow the skill files), plus `k2f` on PATH. Documented compatibles include **Cursor**, **Claude Code**, **Codex**, **WorkBuddy**, **Manus**, **OpenClaw**, **MUSE**, **Hermes**, **Pi Agent**, **Grokbot**, and similar. Copy-paste the one-line prompt; no K2F account or OAuth is required for local skill + Gallery workflows.

### Is MCP required?

**No.** MCP stdio (`k2f_mcp`) is optional for template listing/download in some setups. The skill explicitly continues from `starter/` or Gallery fetch if MCP is missing. **Remote HTTP MCP is not shipped** (roadmap).

### What mistakes do new users and agents make most often?

| Mistake | Fix |
|---------|-----|
| Empty lower third on a designed page | Copy filled-page patterns from skill catalog; verify PNG preview, not only `pack_verify` exit code |
| Using `____` or `□` for forms | Use `form_field` nodes (`ex_form.json`); export AcroForm PDF |
| Putting `color` / `font_size` on content nodes | Move styling to `theme.json` roles |
| Editing `document.K2F.lock` by hand | Edit tree/theme → pack → compile |
| Expecting preview to update after JSON edits without compile | Run pack/compile; viewers paint the lock |
| Hand-counting UTF-8 byte ranges for `modifiers` | Use `modifier_range.py` from the skill |

### Can an agent restyle the entire document at once?

Yes. Change `styles/theme.json` (palette, role definitions, primitives) and recompile. Semantic structure stays; appearance updates globally. This is **semantic-first restyling** — distinct from selecting all text in Word and applying a style.

---

## 5. Exports and delivery

### Which formats can I export?

From a **compiled** `.K2F` (published lock), the reference engine supports drawing to:

- **PDF** — default includes **fillable AcroForm** for `form_field` nodes; `--flatten` for static glyphs only
- **DOCX** — Word
- **PPTX** — PowerPoint
- **IDML** — InDesign (package folder with `Document Fonts/` by default)
- **Markdown** — via `k2f_to_markdown` / bridge APIs
- **Images** — raster preview paths in CLI and viewers

See [exporting overview](https://k2f.dev/docs/guide/exporting) on the docs site.

### How do fillable PDFs work?

Define blanks and checkboxes as semantic **`form_field`** nodes in the content tree. After compile, default PDF export embeds **AcroForm** widgets at lock positions. Viewers can overlay inputs and save via relock workflows.

**Word and PowerPoint exports draw boxes and text from the lock — they are not interactive Office form controls.** For fillable behavior, deliver PDF.

### Can I import Word, PowerPoint, PDF, or IDML into K2F?

**No.** One-way export only:

- `DOCX_IS_NOT_A_SOURCE`
- `PPTX_IS_NOT_A_SOURCE`
- `PDF_IS_NOT_A_SOURCE`
- `IDML_IS_NOT_A_SOURCE`

Build or convert **into** K2F via Markdown bridge, Gallery templates, agent authoring, or SDK — not by importing Office binaries as authority.

### What about signing and integrity?

Packages can carry `content_hash` and `appearance_hash` on the lock. Optional **Ed25519** signatures in `signatures/v1.json` support integrity workflows. Viewers report states such as `SIGNED`, `UNSIGNED`, `BROKEN_INTEGRITY`, `ENGINE_MISMATCH`. **Agent-generated files are often `UNSIGNED` by design** — organizational signing is a separate step.

---

## 6. Gallery and templates

### Is the Gallery free?

Yes. **No account, no paywall, no watermarks, no download caps** for templates on [k2f.dev/gallery](https://k2f.dev/gallery). Use them with any agent or locally.

### What do I get for each template?

Each production template typically includes downloads for:

- **`.K2F`** — editable semantic source
- **Word (DOCX)**
- **PowerPoint (PPTX)**
- **IDML**

One design, multiple handoff formats — without maintaining four unrelated source files.

### How should agents use Gallery templates?

Fetch the template package (Gallery API or MCP `download_template` when available), save `.K2F` to disk, `k2f unpack` to `source/`, edit JSON, recompile. **Do not** load the entire ZIP into the chat context. Templates are **living semantic packages**, not preview JPEGs.

---

## 7. Ecosystem and tooling

### Can I embed K2F in my product?

Yes. Use npm `@openk2f/k2f`, WASM init, and `<k2f-viewer>` for in-app preview; call export APIs after compile. Apache 2.0 on the format and engine supports embedding in SaaS report generators, contract pipelines, and education platforms.

## 8. Privacy, security, and data handling

Evaluators often ask: *Does using K2F mean sending my document to your servers?* *Can we run this on-premises?* *What about confidential content with AI agents?* This section separates the **open format + local engine** from **optional k2f.dev services** and from **your AI provider**.

### Do I have to upload my documents to K2F to use the format or engine?

**No.** The `.K2F` format and the reference engine (`pip install k2f`, Desktop Reader, embedded WASM in your own app) run **on your machine or in your infrastructure**. Authoring, compile, verify, and export can all happen **without** creating a K2F account or posting package bytes to k2f.dev.

You only send bytes to k2f.dev when you **choose** a hosted feature (below) — for example clicking **Save & share** or **Publish** in Playground, or downloading a public Gallery template over HTTPS.

### What runs locally vs what touches k2f.dev?

| Activity | Typical data flow |
|----------|-------------------|
| Agent + skill + `k2f` CLI on your laptop | Stays on your machine (and whatever paths **you** configure). No K2F account. |
| `k2f pack` / `compile` / `export-*` / `verify` | Local only. |
| Desktop Reader open / export | Local only. |
| Embed `<k2f-viewer>` in **your** product with local bytes | Your hosting; K2F WASM runs in the user’s browser — you control whether bytes hit your backend. |
| Browse docs or Gallery on k2f.dev | Normal web requests; Gallery **downloads** public template bytes (you are not uploading your doc). |
| Playground: drop `.K2F` or compile Markdown | Preview/compile uses **in-browser** engine paths; your file is not uploaded until you click share/publish. |
| Playground: **Save & share** | **Upload:** full `.K2F` ZIP stored server-side for **24 hours** → link `/p/{uuid}`. |
| Playground or API: **Publish** (permanent) | **Upload:** locked package stored keyed by `appearance_hash` → public `/v/{hash}` (max **8 MiB** per package on the public site). |
| Permanent publish on **your own** K2F site | Same publish model if you self-host the site stack with a database — you control the origin. |

If you never click share/publish and never use hosted APIs, treat K2F like any local file tool chain.

### I use an AI agent with the K2F skill — who sees my content?

Two different boundaries:

1. **K2F tooling** — The skill scripts and `k2f` CLI run where **you** run the agent (local disk, your CI, your VM). They do not, by themselves, upload your semantic JSON to K2F unless you invoke a k2f.dev share/publish API or similar.
2. **The LLM / agent product** — Cursor, Claude, ChatGPT, Codex, etc. send prompts and file context to **their** cloud (or your enterprise deployment) under **their** terms. Putting contract text in `content/root.json` and asking the agent to edit it means that text may be processed by **that provider**. For confidential material, use your org’s approved agent deployment, redaction policies, and **local-only** compile/export — same as you would for any AI coding or writing tool.

K2F does not replace your vendor review of AI subprocessors; it gives you a **local, auditable file** once the agent writes to disk.

### Am I locked in if k2f.dev changes or goes away?

**No** for the format itself:

- Spec and schemas are open; `.K2F` files remain on your disks and Git repos.
- Engine source is on GitHub; you can build or pin SDK versions.
- Exports (PDF, DOCX, PPTX, IDML) are standard delivery formats your org already archives.

Hosted Gallery, Playground, and `/v/` links are **convenience**; core value does not require them.

### Can I use K2F commercially?

Yes. Apache 2.0 applies to the format and reference engine — embed in products, run as a service internally, ship generated documents to customers. Respect third-party **font licenses** embedded in your packages and trademark guidance on [k2f.dev](https://k2f.dev/trademark) for the K2F name/logo in your marketing.

## 9. Version control and collaboration

### Why is K2F better in Git than DOCX?

Office files are binary ZIPs with opaque XML. K2F sources are **JSON** with meaningful diffs: you see which `id` changed, not a wall of hex. Pair with code review culture for policies, reports, and agent-generated documents.

### Can I roll back one section without reverting the whole file?

Yes, in principle: stable node ids and tree structure let agents or humans patch specific subtrees. Optional `changelog.json` records edit history. For Git history, revert commits on `content/` or individual fragment files when using includes.

## 10. Comparisons with other formats and tools

### Can I convert a PDF into K2F?

**No.** `PDF_IS_NOT_A_SOURCE`. PDF export **draws** the published lock. Treat PDF as a read-only rendering, not authoritative document state.

### Is K2F built for native slide-deck or whiteboard authoring?

**Not yet.** Today’s shipped surface is **`canvas_mode: "paged"`** documents. Slide mode and infinite canvas are roadmap. Many templates still **export to PPTX** so presentation handoff stays in the PowerPoint ecosystem your team already uses.

## 12. Limits, roadmap, and trust

### How stable is the K2F format today?

The on-disk contract is **[format spec v0.3](https://k2f.dev/spec)**, shipped with the **0.3.x** SDK line on PyPI, npm, and crates.io. Across the early release line, **schema and package shape evolved slowly** — the jump from earlier previews to **v0.3** was incremental rather than a rewrite.

**Today:**

- **Patch SDK releases** (0.3.1, 0.3.2, …) keep spec **v0.3** unless embedded schemas or the lock format must break.
- **Current 0.3.x tools are intended to open and work with packages produced on the supported v0.3 line** — unpack, compile, verify, view, and export without treating every file as legacy.
- **`ENGINE_MISMATCH`** means the reader build differs from the compiler recorded on the lock — provenance, not a corrupt file. Recompile when you want the lock aligned with your current engine.

Older **0.2.x and earlier** SDK lines are **not** security-supported; use current **0.3.x** for production. Full policy: [Compatibility](https://k2f.dev/compatibility) and [Changelog](https://k2f.dev/changelog).

### What is shipped today (honest scope)?

- **Format spec v0.3**, CLI/SDK **0.3.x** on PyPI, npm, crates.io
- **`canvas_mode: "paged"`** documents
- Export: PDF (incl. AcroForm), DOCX, PPTX, IDML, Markdown, images
- Web viewer, Playground, agent skill, **MCP stdio**
- Desktop Reader installers — **preview** (unsigned; OS trust workflows roadmap)

### What is not shipped yet?

| Item | Notes |
|------|-------|
| **Slide / infinite canvas modes** | Design targets; not v0.1 |
| **Remote HTTP MCP** | Planned; stdio only today |
| **Desktop code signing / notarization** | Installers exist; trust workflows roadmap |
| **Import DOCX/PDF/PPTX/IDML as sources** | By design — one-way export |

### What if I see `ENGINE_MISMATCH` or `BROKEN_INTEGRITY`?

Recompile with the current supported engine, or open with the engine version that produced the lock. Do not edit locks manually. See [Integrity](https://k2f.dev/integrity) on the site.

---