---
title: ScaiLog
path: index
status: published
---

# ScaiLog

ScaiLog is GDPR-native central logging. You mark personal information (PI) at
the level of individual named fields, ScaiLog encrypts each subject's PI under a
per-subject key, and erasing a person is a cryptographic operation — destroy the
key and their PI is unrecoverable everywhere it was ever written. Every entry
carries a developer-assigned `call_site_id`, so remediation is "fix one call
site." It runs as one binary over one SQLite file in standalone mode, ships four
wire-identical SDKs (Python, TypeScript, Go, .NET), and has **zero Scai\*
runtime dependencies** — it is the foundational logger everything else logs
into, so it must boot with nothing else running. ScaiLog is Apache-2.0.

## What ScaiLog does

ScaiLog gives you structured application logging that treats personal data as a
first-class, governed thing rather than free text you hope stays clean.

- **Field-level PI marking.** You wrap a field value with `pi(value, pi_type)`.
  The marker attaches to that named field only — never to the whole entry and
  never to the free-text `message`, which is indexed for search in plaintext and
  must stay PI-free.
- **Cryptographic per-subject erasure.** Each data subject's PI is encrypted
  under a per-subject data-encryption key (DEK) derived from a tenant key, which
  derives from a root key. Erasure destroys the subject's DEK, which renders
  their encrypted PI permanently unreadable across the whole store. This ships in
  Phase 1, not "later."
- **Call-site provenance.** Every entry records the `call_site_id` the developer
  assigned at the log statement. You can see exactly which call sites emit which
  PI types, and fix leaks at the source.
- **Policy-driven handling.** A declarative YAML policy decides, per PI field,
  whether to `encrypt`, `redact`, `drop`, or `keep` it, plus retention. The
  resolved policy version is frozen into each entry so old entries stay
  explainable forever.
- **DSAR and erasure with signed receipts.** Run a subject access request or an
  Article 17 erasure from the CLI or the API. Both produce Ed25519-signed
  documents you can verify offline against the server's published report keys.
- **Standalone-first deployment.** `scailog-server --standalone` is one process
  and one SQLite file, with the per-host agent role embedded. Scaling up is a
  deployment choice (Litestream, rqlite, tenant sharding), never a rewrite.

ScaiLog is a logger, not an alerting or APM product. It does not do metric
tiers, on-call paging, or anomaly detection — it does governed, searchable,
erasable logs.

## Core ideas

If you read nothing else, read these concepts:

- [PI marking & call-site provenance](/docs/scailog/concepts/pi-and-call-sites)
  — why markers attach to fields and never to `message`, and how the
  `call_site_id` contract drives remediation.
- [Encryption and cryptographic erasure](/docs/scailog/concepts/encryption-and-erasure)
  — the per-subject key hierarchy and what "destroy the key" actually deletes.
- [The policy engine](/docs/scailog/concepts/policies) — the four actions
  and most-specific resolution.

## Get started

Go to the [Quickstart](/docs/scailog/quickstart) to run a standalone server,
emit a log with a PI field, and take that field from written to decrypted (via
DSAR) to cryptographically erased in five copy-pasteable steps. Then browse the
[Guides](/docs/scailog/guides) for DSAR, erasure, and policy authoring.