The answers an OSS review asks for.

Before an enterprise adopts an open-source dependency, somebody runs a review: where does the data live, who patches it, what happens if the maintainer disappears. This page holds the answers in one place — every claim links to the committed document that holds it, because nothing here is new. The honest answers, including the uncomfortable ones, are below; the checklist table at the end is made to be pasted into a review.

Where it runs, and what leaves

ochakai is not a SaaS. You deploy it into your own Google Cloud project — one Go binary and Postgres on Cloud Run + Cloud SQL — and there is no vendor side for your data to reach. The only hosts it contacts are Google Cloud APIs in your own project, and there is no telemetry: nothing is reported anywhere, and no opt-out to configure because there is nothing to opt out of.

Storage is your project's Cloud SQL (Postgres) and, for files, your project's GCS bucket — ochakai brings no storage of its own, so your existing region, encryption and backup posture applies as-is. And the knowledge is never a hostage: the whole base round-trips out as an OKF v0.2 bundle — markdown and YAML that lives happily in git — and can be purged on request (condition C1).

Zero secrets, and what replaces authorization

There is no API key, no password, no token to issue or rotate — anywhere. Cloud Run IAM decides who can reach a deployment, Cloud SQL IAM authenticates the database, and the web UI for a team goes behind IAP. This is a design decision with its own records (0003, 0065), and it is why production is Google Cloud only, on purpose.

Just as deliberately, there is no per-concept authorization: whoever can reach a deployment can read and write, and identity is recorded as provenance rather than checked as permission. Separation is per deployment — a tenant, a team, a sensitivity level each get their own instance, practical at about $10/month apiece. If you need per-concept permissions, the positioning page says plainly: this is the wrong tool.

The audit trail

Every write carries provenance — who wrote it, as observed from the authenticated caller, never as a self-description the caller typed. Verifications and rejections are appends to a ledger with the actor and the moment; every change to a concept is kept as a revision; a rejection keeps its reason. Reachability itself is logged on your side, by Cloud Run, in your project's Cloud Logging — the operating guide (Japanese) covers what to read and what to alert on.

Supply chain

Images are published to ghcr.io/na0fu3y/ochakai with an SBOM and SLSA provenance attached to the manifest; the CI workflows' actions are pinned by commit SHA; the binary is a static, trimmed-path Go build on distroless/static; and govulncheck runs in CI. Verify what you are about to deploy:

gh attestation verify oci://ghcr.io/na0fu3y/ochakai:<tag> -R na0fu3y/ochakai
# release archives: gh attestation verify <file> -R na0fu3y/ochakai

CLI release archives carry the same attestation plus checksums.txt, and Binary Authorization can enforce the image check at deploy time — the operating guide's supply-chain and hardening sections (Japanese) have the steps.

Vulnerabilities, fixes, and the support policy

Vulnerabilities are reported privately via GitHub Security Advisories (SECURITY.md), with a response within a few days. A fix ships in the next release, and here is the policy stated plainly rather than discovered later: only the latest release is supported. There is no support window and no backporting (docs/compatibility.md).

What makes that survivable in production is written down in the same document: REST is frozen at /api/v1 and CI fails on any drift from the frozen contract, every breaking change to the still-unstable surfaces (MCP, CLI, stored shape) is marked BREAKING in the changelog with what an operator does about it, the deploy guide pins image tags so an upgrade is a decision, and ochakai export is both your backup and your exit at every moment.

Continuity — the one-maintainer question

ochakai is maintained by one person, and no page on this site hides it (SUPPORT.md says it in its first sentence). The continuity answer is not a promise about the maintainer; it is that nothing about your deployment is held by the maintainer: the code is MIT, your knowledge round-trips out as OKF, the wire contract is a frozen OpenAPI document, and every decision that shaped the product — including what was refused and why — is public as numbered, immutable design records. A team that had to take over would inherit the reasons, not just the code.

The checklist, pre-filled

The rows a security review sheet usually asks, answered with the link that proves each one.

License: MIT (LICENSE, copyright Naofumi Yamada).
Delivery model: Self-hosted OSS in your own Google Cloud project. No SaaS, and no commercial support contract exists (SUPPORT.md).
Where data lives: Your project's Cloud SQL (Postgres) and GCS. No data leaves your project; no telemetry.
Third-party certifications (ISO 27001, SOC 2): Not applicable to the software itself: ochakai is not a service processing your data — the audit surface is your own Google Cloud project, where it runs.
Authentication: Cloud Run IAM (Google identities); IAP in front of a team web UI. No API keys, tokens or passwords exist to leak (design records 0003, 0065).
Authorization: None, by recorded decision: reachability is the access model. Separation is per deployment (an instance per tenant/team at ~$10/month). Per-concept permissions → wrong tool.
Audit trail: Provenance on every write (observed from the authenticated caller), verify/reject ledger, full revision history, rejections keep their reason. Access logs are your Cloud Run logs.
Vulnerability reporting: Private, via GitHub Security Advisories; response within a few days (SECURITY.md).
Dependency scanning: govulncheck runs in CI on every push (ci.yaml), and locally via scripts/check vuln.
SBOM & build provenance: Image manifests carry an SBOM and SLSA provenance; verifiable with gh attestation verify. Workflow actions pinned by commit SHA; static Go binary on distroless.
Supported versions: The latest release only — no backporting, stated as policy in docs/compatibility.md. REST is frozen at /api/v1; breaking changes elsewhere are marked BREAKING in the changelog.
Backups & exit: Cloud SQL automated backups plus ochakai export — a full OKF bundle that is both logical backup and exit (operating guide, Japanese).
Intended scale: A curated base — thousands of concepts, not millions, because every one passes a human (positioning).
Business continuity: One maintainer, honestly stated. MIT license + whole-base OKF export + a frozen wire contract + public immutable design records keep the exit open at every moment.

A question this page does not answer is probably in the FAQ or positioning; for anything else, Discussions is where questions go.