@panaversity/ksor 0.0.40 → 0.0.41

package/dist/gateway.d.mts

@@ -1,7 +1,7 @@
 import { CallToolResult, McpServer as McpServer$1, StandardSchemaWithJSON } from "@modelcontextprotocol/server";
 import { z as z$1 } from "zod";
 import pg from "pg";
-//#region ../content-gateway/dist/gateway-api-D9COH1tR.d.mts
+//#region ../content-gateway/dist/gateway-api-Da-9ssbU.d.mts
 //#region src/instructions.d.ts
 /**
  * Has the owner said what this record is FOR yet?
@@ -16,6 +16,10 @@ import pg from "pg";
 declare function recordIsUndescribed(authored: string): boolean;
 declare function composeInstructions(authored: string): string;
 //#endregion
+//#region ../content/dist/index-CQcB_oVG.d.mts
+declare const TRUST_TIERS: readonly ["unverified", "machine-confirmed", "human-reviewed"];
+type TrustTier = (typeof TRUST_TIERS)[number];
+//#endregion
 //#region ../content/dist/index.d.mts
 //#endregion
 //#region src/lib/abstain.d.ts
@@ -45,26 +49,40 @@ interface AbstainConfig {
    * never set one by intuition, recalibrate per corpus.
    */
   readonly keywordFloor: number | null;
+  /**
+   * The digest of the retrieval predicate {@link vectorFloor} was MEASURED
+   * under (`GATE_PREDICATE_DIGEST`), or null on a record that declares none.
+   *
+   * A number alone cannot say which candidate set it separated, so a floor
+   * carried across a predicate change reads as calibrated while gating a set
+   * it was never measured on. The door compares this at boot and refuses on a
+   * mismatch — the declared-but-uncalibrated state, not `gate: off`.
+   */
+  readonly floorDigest: string | null;
 }
 interface ContentInstance {
-  /** The corpus identity — instance.md's `name:` (the path/name IS the identity). */
+  /** The corpus identity — instance.md's `name:` (the one sanctioned identity key). */
   readonly name: string;
   readonly corpusId: string;
   readonly tenantId: string;
+  /** The display title (the root index's heading) and the one-sentence description that seeds `llms.txt` and `server.json`. */
+  readonly title: string;
+  readonly description: string;
+  /** The upgrade stamp `ksor init` wrote; null on a hand-written instance. */
+  readonly toolchain: {
+    readonly requires: string;
+    readonly scaffolded: string;
+  } | null;
   /** The NAME of the env var holding the DSN; the composition root resolves it. */
   readonly dsnEnv: string;
   readonly abstain: AbstainConfig;
   readonly maximumResponseCharacters: number;
-  /** The authored agent-surface instructions (the body, edge-trimmed). */
+  /** The MCP server's instructions (the body, edge-trimmed). */
   readonly instructions: string;
   /** Transport name (registry key, never persisted). */
   readonly embeddingProvider: string;
-  /** The record's reader audiences, least- to most-restricted; empty = no model. */
   /** The Postgres text-search configuration the keyword arm stems with. */
   readonly textSearchConfig: string;
-  readonly audiences: readonly string[];
-  /** The tier a document takes when it declares none; null = none declared. */
-  readonly defaultVisibility: string | null;
   /** model + dim are the persisted IDENTITY of the embedding space. */
   readonly embeddingModel: string;
   readonly embeddingDim: number;
@@ -86,12 +104,23 @@ interface ServiceContext {
   /** The verified caller, or null → audited as "anonymous". */
   readonly actor?: () => string | null;
   /**
-   * The audience tier this door serves. null = the record's least-privileged
-   * tier, which is the safe default: a door that cannot establish who is asking
-   * must not hand out the restricted half of the record. Ignored entirely when
-   * the instance declares no `audiences:` model.
+   * The viewer list this door serves (record spec §2.4) — validated against the
+   * ingested policy's registry at boot (`validateViewer`), always including
+   * `public`. Absent = `[public]`, the safe default: a door that cannot
+   * establish who is asking must not hand out the restricted half of the record.
    */
-  readonly audience?: string | null;
+  readonly viewer?: readonly string[];
+  /**
+   * The lowest trust tier this door will answer from (record spec §2.3):
+   * 0 unverified, 1 machine-confirmed, 2 human-reviewed. Absent = 0, which
+   * admits every tier — the honest default, since `verified` is never required
+   * and a record with no verifications is a legitimate level-0 state.
+   *
+   * Bound as an ARM predicate, never applied to the hits afterwards: a floor
+   * enforced after ranking has already let a lower-tier passage decide what
+   * the answer was.
+   */
+  readonly minTrustTier?: TrustTier | number;
 }
 /**
  * The largest outline a caller may ASK for. The tool schema and the service
@@ -123,6 +152,16 @@ declare const READ_OUTPUT: StandardSchemaWithJSON;
 interface SearchArgs {
   readonly query: string;
   readonly k: number;
+  /**
+   * The lowest trust tier the caller will accept an answer from.
+   *
+   * OPTIONAL on the handler, not on the wire, and that is the point: the
+   * registration file is adopter-owned code (decision 23), so a record
+   * scaffolded before this parameter existed keeps working — the handler
+   * supplies `unverified`, which is what it always had. The boot inspection
+   * NOTICES the absence and never refuses it.
+   */
+  readonly min_trust_tier?: TrustTier | undefined;
 }
 declare function searchHandler(ctx: ServiceContext): (args: SearchArgs) => Promise<CallToolResult>;
 interface OutlineArgs {
@@ -141,4 +180,4 @@ interface ReadArgs {
 }
 declare function readHandler(ctx: ServiceContext): (args: ReadArgs) => Promise<CallToolResult>;
 //#endregion
-export { FLOOR, MAX_OUTLINE_LIMIT, MAX_SEARCH_K, McpServer$1 as McpServer, OUTLINE_OUTPUT, type OutlineArgs, READ_ONLY, READ_OUTPUT, type ReadArgs, SEARCH_OUTPUT, type SearchArgs, type ServiceContext, composeInstructions, outlineHandler, readHandler, recordIsUndescribed, searchHandler, z$1 as z };
+export { FLOOR, MAX_OUTLINE_LIMIT, MAX_SEARCH_K, McpServer$1 as McpServer, OUTLINE_OUTPUT, type OutlineArgs, READ_ONLY, READ_OUTPUT, type ReadArgs, SEARCH_OUTPUT, type SearchArgs, type ServiceContext, TRUST_TIERS, type TrustTier, composeInstructions, outlineHandler, readHandler, recordIsUndescribed, searchHandler, z$1 as z };

package/dist/gateway.mjs

@@ -1,2 +1,2 @@
-import { L as z$1, O as readHandler, a as MAX_OUTLINE_LIMIT, d as READ_OUTPUT, f as SEARCH_OUTPUT, j as searchHandler, k as recordIsUndescribed, l as OUTLINE_OUTPUT, o as MAX_SEARCH_K, r as FLOOR, s as McpServer$1, u as READ_ONLY, w as outlineHandler, y as composeInstructions } from "./gateway-api-CmIthmJS-IUA9qS-T.mjs";
-export { FLOOR, MAX_OUTLINE_LIMIT, MAX_SEARCH_K, McpServer$1 as McpServer, OUTLINE_OUTPUT, READ_ONLY, READ_OUTPUT, SEARCH_OUTPUT, composeInstructions, outlineHandler, readHandler, recordIsUndescribed, searchHandler, z$1 as z };
+import { D as outlineHandler, I as searchHandler, N as readHandler, P as recordIsUndescribed, W as z$1, c as McpServer$1, d as READ_ONLY, f as READ_OUTPUT, h as TRUST_TIERS, i as FLOOR, o as MAX_OUTLINE_LIMIT, p as SEARCH_OUTPUT, s as MAX_SEARCH_K, u as OUTLINE_OUTPUT, x as composeInstructions } from "./gateway-api-CF4ED9_g-BQusM_dK.mjs";
+export { FLOOR, MAX_OUTLINE_LIMIT, MAX_SEARCH_K, McpServer$1 as McpServer, OUTLINE_OUTPUT, READ_ONLY, READ_OUTPUT, SEARCH_OUTPUT, TRUST_TIERS, composeInstructions, outlineHandler, readHandler, recordIsUndescribed, searchHandler, z$1 as z };

package/dist/index.d.mts

@@ -21,7 +21,7 @@ declare const exitCodes: {
 type ExitCode = (typeof exitCodes)[keyof typeof exitCodes];
 /** The CLI vocabulary. Lifecycle verbs plus the corpus operations the bundled
  * kernel provides (one binary — decision 12 publish revision). */
-declare const verbs: readonly ["init", "dev", "build", "serve", "ingest", "schema", "grant", "takedown", "calibrate", "gc"];
+declare const verbs: readonly ["init", "dev", "build", "migrate", "serve", "ingest", "schema", "grant", "takedown", "calibrate", "gc"];
 type Verb = (typeof verbs)[number];
 interface ResolvedCommand {
   /** The first non-flag token, or null when only flags (or nothing) appear. */

package/dist/index.mjs

@@ -1,2 +1,2 @@
-import { n as resolveCommand, r as verbs, t as exitCodes } from "./src-pl4aOpVs.mjs";
+import { n as resolveCommand, r as verbs, t as exitCodes } from "./src-dqpI-p1a.mjs";
 export { exitCodes, resolveCommand, verbs };

package/dist/{src-pl4aOpVs.mjs → src-dqpI-p1a.mjs}

@@ -24,6 +24,7 @@ const verbs = [
 	"init",
 	"dev",
 	"build",
+	"migrate",
 	"serve",
 	"ingest",
 	"schema",

package/docs/authorization.md

@@ -12,7 +12,7 @@ authorization server and pointing the door at it.
 This page is four worked recipes, all executed against real servers rather than
 written from their documentation, plus what an agent does to obtain a token. The
 mechanism is standard OAuth 2.0 — nothing here is specific to any one product,
-and that is the point: three different implementations are shown because a
+and that is the point: four different implementations are shown because a
 single one proves nothing about neutrality. Two are self-hosted (one `docker
 run` each, no account), one is a hosted commercial provider with a free tier,
 and one is an organization's own SSO — which is the case that matters most,
@@ -41,9 +41,11 @@ per-request case needs a decision first.
 **It is one gate, not per-user rules.** The door checks that a token was signed
 by the issuer you named and audienced at this record. It reads no scopes, no
 roles, no groups. **Any caller holding a valid token gets the whole record**, to
-the extent the audience tier allows. If different readers must see different
-documents, that is the record's `audiences:` / `visibility:` model, and it is a
-different mechanism from this page — see the scaffold's AGENTS.md.
+the extent its audience list allows. If different readers must see different
+documents, that is the record's audience model — the registry in
+`.ksor/governance.yaml`, each concept's `ksor.audience` list, and the viewer
+list the door is configured for — and it is a different mechanism from this
+page. See the scaffold's AGENTS.md.
 
 So: this page answers _"can a stranger read my record over MCP?"_ It does not
 answer _"can Alice read what Bob can."_
@@ -67,7 +69,7 @@ works, not while you are trying to make it work.
 to anyone who can reach the port — and it wins over everything below. A scaffold
 ships with `KSOR_AUTH=disabled-local` in its `.env.example`, so a deployment
 that copied that file has it set and will stay unauthenticated no matter how
-carefully you configure the four variables above. Configuring the SSO door is
+carefully you configure the variables above. Configuring the SSO door is
 what turns auth **on**; removing `KSOR_AUTH` is what stops it being off.
 
 Every variable here is read from the environment of the `ksor serve` process —
@@ -190,7 +192,7 @@ opaque by default, no OAuth token endpoint taking a custom audience, no metadata
 document. That is a coherent design; it is simply a different one, and adapting
 it means writing the verification layer ksor already is.
 
-The three recipes below all pass. If yours does too, they will read as the same
+The four recipes below all pass. If yours does too, they will read as the same
 recipe with different button names — because underneath they are.
 
 ## Recipe: Keycloak

package/docs/deploying.md

@@ -82,16 +82,21 @@ The emitted `Dockerfile` names no host. It installs the pinned
 
 ```sh
 docker build -t my-record .
-docker run --rm -p 8080:80 --env-file .env my-record
+docker run --rm -p 8080:80 --env-file .env \
+  -e KSOR_AUTH=disabled-public my-record
 ```
 
 Two things about that command, both of which bite:
 
 - **The image listens on 80**, which is why the mapping is `8080:80`. If your
   `.env` sets `PORT`, change the right-hand side to match.
-- **`.env` must contain `KSOR_AUTH=disabled-public`, even locally.** A container
-  gets `$PORT` and therefore binds `0.0.0.0` — a public bind — and
-  `disabled-local` refuses there by design. Your laptop is not the exception.
+- **`KSOR_AUTH=disabled-public` is required, even locally.** A container gets
+  `$PORT` and therefore binds `0.0.0.0` — a public bind — and the
+  `disabled-local` a scaffolded `.env` carries refuses there by design. Your
+  laptop is not the exception. Pass it with `-e` rather than editing `.env`, so
+  a plain `ksor serve` outside the container keeps its loopback posture; `-e`
+  overrides `--env-file`. A real deployment sets it — or the SSO variables — in
+  the host's environment, since `.dockerignore` keeps `.env` out of the image.
 
 That runs on Cloud Run, Fly, Render, ECS, Kubernetes, or a VPS with no changes.
 `vercel.json` **points at this same file** rather than replacing it, which is
@@ -234,22 +239,20 @@ rebinding is worth an attacker's effort only when it reaches something they coul
 not reach directly. With `KSOR_AUTH=disabled-public` the record is already served
 to anyone who types the URL, so there is nothing for rebinding to steal.
 
-### The site build needs the DSN too
+### The site build runs `ksor build` first
 
-Once `instance.md` declares a `database:` block, `pnpm build` runs
-`pnpm export-denylist` first — it asks the database what has been withdrawn and
-writes `.ksor-denylist.json`. Without `KSOR_DB_URL` the build **refuses**:
+`pnpm build` is `ksor build` followed by the site build. `ksor build` needs no
+database: it regenerates every `index.md`, runs the record checker, and writes
+`build.lock.json` — commit it — which every machine artefact stamps. A refusal
+stops the build before a byte is written; `--strict` also refuses an
+uncommitted input. Takedowns reach the site through the committed ledger
+(`.ksor/takedowns.yaml`), which is a file in the repository — so the site build
+needs no `KSOR_DB_URL` at all.
 
-```
-KSOR_DB_URL is unset, and instance.md declares a database
-  why: a takedown lives in that database. Without it this build cannot tell
-       'nothing is denied' from 'nobody asked'
-```
-
-That refusal is the design working. A takedown reaches the door instantly (it is
-a row) and reaches the site at its next build (it reads a file), so a site built
-without the DSN would keep publishing what the door already refuses. Set
-`KSOR_DB_URL` on the site build as well as on the door.
+That is the design working. A takedown reaches the door instantly (it is a row)
+and reaches the site at its next build (it reads the ledger), so the act that
+withdraws a document is the same merged commit on both surfaces. Merge the
+ledger entry, rebuild, redeploy.
 
 ## Keeping people out of the site
 
@@ -282,12 +285,20 @@ nothing.
 
 ### "Some documents are restricted, most are not"
 
-**Build per audience.** `KSOR_AUDIENCE=<tier> pnpm build` stages only what that
-tier may see, so restricted documents are **never written into the artifact** —
-enforcement by absence, which is the only kind a static host can honour. Publish
-the public artifact openly and the wider one behind the gate above.
+**Build per audience.** `KSOR_AUDIENCE=public,internal pnpm build` stages only
+what that viewer may see, so the concepts it may not are **never written into
+the artifact** — enforcement by absence, which is the only kind a static host
+can honour. Publish the public artifact openly and the wider one behind the
+gate above.
+
+The value is a comma list of registered audiences and it must include `public`
+— a bare `KSOR_AUDIENCE=internal` is refused (`ksor-viewer-omits-public`),
+because every reader of a restricted build is also a reader of the open one and
+a build for the restricted audience alone would silently drop every public
+concept. A concept is staged when its `ksor.audience` list overlaps the
+viewer's; there is no ordering between audiences to be narrower or wider than.
 
-Plain `pnpm build` is always the public tier, so the safe thing is the default.
+Plain `pnpm build` is `[public]`, so the safe thing is the default.
 
 ### "Different readers see different documents, decided per request"
 
@@ -428,8 +439,8 @@ connections** — the pool minimum is 0 and an unused connection closes after 10
 first request after a suspend both wakes the database and retries the connect
 rather than failing.
 
-Measured against a live deployment on Vercel, Neon behind it, an 81-document
-record of 6,963 chunks:
+Measured 2026-08-23 against a live deployment on Vercel, Neon behind it, an
+81-document record of 6,963 chunks, and not re-measured since:
 
 |                                        |           |
 | -------------------------------------- | --------- |

package/docs/index.md

@@ -31,10 +31,14 @@ instead of their training memory. The corpus grows with each implemented verb.
   needing Postgres and a provider key — alongside the write plane that keeps
   the record current: `ksor schema` (provision or migrate the database),
   `ksor grant` (authorize a tenant for ingest), `ksor ingest` (build and publish
-  a generation), `ksor takedown` (withdraw a document from EVERY surface, and
-  export the manifest the site build reads), `ksor calibrate` (measure the
-  abstention floor) and `ksor gc` (reap retired generations). Only `ksor dev` and `ksor build` remain designed, not
-  implemented: each prints an honest notice and exits `2`.
+  a generation), `ksor takedown` (withdraw a document from EVERY
+  surface — the committed ledger first, the denylist row second, so a record
+  with no database can withdraw one), `ksor calibrate` (measure the
+  abstention floor) and `ksor gc` (reap retired generations). `ksor build`
+  (check the record, generate its indexes, write `build.lock.json`) and
+  `ksor migrate` (rewrite a pre-profile record into the KSoR Profile — a diff
+  first, `--write` to apply) need no database. Only `ksor dev` remains designed, not implemented: it prints an
+  honest notice and exits `2`.
   - **[tool-surface.md](./tool-surface.md)** — shaping what agents see.
     `system/gateways/content.ts` is emitted, adopter-owned and deletable; it
     decides tool names, what the record says it covers, and how much of the
@@ -62,15 +66,24 @@ instead of their training memory. The corpus grows with each implemented verb.
 ## For the agent operating a scaffolded project
 
 Read the scaffold's own `AGENTS.md` first — it is the working contract.
-Knowledge lives in `knowledge/` and never inside the site; frontmatter uses
-a closed key set (`title` + `status` required); `pnpm check` explains any
-violation and how to fix it. Reading order is the governed `order:`
-frontmatter key — never `meta.json` or `sidebar_position` — and it drives
-every surface: the sidebar, `llms.txt`, and the MCP `outline` tool. If the
-instance declares an `audiences:` model, documents may carry a
-`visibility:` key and per-audience builds (`KSOR_AUDIENCE=<tier> pnpm
-build`) stage only what that tier may see — publication, not authorship:
-anyone who can clone reads everything. The site shell
+Knowledge lives in `knowledge/` and never inside the site. A document is an
+OKF concept in the KSoR Profile: `type`, `title`, `description`, `status`
+(`draft | stable | deprecated`) and `ksor.audience` are required, and a
+`stable` one additionally carries `generated` and a `ksor.approval` by an
+actor the Governance Policy authorises. Keys the profile does not know are
+PRESERVED rather than refused; the pre-profile ones (`visibility`, `owner`,
+`provenance`, `effective`, `superseded`, `sor_id`) are refused by name, each
+naming its replacement. `pnpm check` explains any violation and how to fix it.
+Reading order is the governed `order:` frontmatter key — never `meta.json` or
+`sidebar_position` — and it drives every surface: the sidebar, `llms.txt`, and
+the MCP `outline` tool.
+
+Audience is a LIST, matched by overlap. `.ksor/governance.yaml` registers the
+audiences; each concept lists the ones it is for; a build names its viewer as a
+comma list that must include `public`
+(`KSOR_AUDIENCE=public,internal pnpm build`) and stages only the concepts whose
+list overlaps it. It is publication, not authorship: anyone who can clone reads
+everything. The site shell
 at `system/site/` is replaceable behind a five-clause surface contract — the
 shell is a slot, and the contract (render the record, `llms.txt`, per-page md
 artifacts, browser smoke, no authored content) is what a replacement must meet.

package/docs/ingesting.md

@@ -20,12 +20,12 @@ Ingest reads your markdown, sends each new chunk to an embedding provider, and
 writes the result to Postgres. So four things must be true, and none of them is
 created for you.
 
-|                      | what                                                                                                          | how                                                                                            |
-| -------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
-| **The corpus**       | `knowledge/` at your repo root — CommonMark `.md`, one document per file, `title` and `status` in frontmatter | `pnpm check` validates it and explains any violation                                           |
-| **The database**     | Postgres with **pgvector** — `CREATE EXTENSION vector;`                                                       | any managed host; the DDL below needs a role that can create tables                            |
-| **The provider key** | `GEMINI_API_KEY` — the default embedding provider is `gemini-embedding-001`                                   | [aistudio.google.com](https://aistudio.google.com/apikey); the free tier covers a first corpus |
-| **The DSN**          | `KSOR_DB_URL`, named by `instance.md`'s `database.dsn_env`                                                    | uncomment the `database:` block in `instance.md` first                                         |
+|                      | what                                                                                                                                                                              | how                                                                                                                                     |
+| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
+| **The corpus**       | `knowledge/` at your repo root — CommonMark `.md`, one document per file, in the KSoR Profile of OKF: `type`, `title`, `description`, `status` and `ksor.audience` in frontmatter | `pnpm check` validates it and explains any violation; `ksor build` must have written a current `build.lock.json` before ingest will run |
+| **The database**     | Postgres with **pgvector** — `CREATE EXTENSION vector;`                                                                                                                           | any managed host; the DDL below needs a role that can create tables                                                                     |
+| **The provider key** | `GEMINI_API_KEY` — the default embedding provider is `gemini-embedding-001`                                                                                                       | [aistudio.google.com](https://aistudio.google.com/apikey); the free tier covers a first corpus                                          |
+| **The DSN**          | `KSOR_DB_URL`, named by `instance.md`'s `database.dsn_env`                                                                                                                        | uncomment the `database:` block in `instance.md` first                                                                                  |
 
 Both variables go in `.env` beside `instance.md` — `ksor` reads it automatically,
 and `.env` is gitignored. Every command below is run **from your repository
@@ -55,6 +55,24 @@ serves immediately; the website is a static build and only changes when you
 rebuild and redeploy it. Ingest alone leaves the human surface showing the old
 content, which reads as a half-failed ingest and is not one.
 
+## When ingest says the lock is stale
+
+`ksor ingest` refuses a record whose `build.lock.json` does not match the tree
+(`ksor-lock-stale`), or that has none at all (`ksor-lock-missing`). **The fix is
+always `ksor build` in that directory — never an edit to the lock.** The lock is
+what says which bytes were checked; editing it to agree with the tree asserts a
+check that never ran, which is the one thing it exists to prevent.
+
+Freshness covers **seven** sets, not just your documents: `instance.md`,
+`.ksor/governance.yaml`, `.ksor/takedowns.yaml`, the concepts, the companions,
+the assets, and the generated `index.md` files. So a refusal can name a file you
+would not think of as content — the policy, the takedown ledger, a diagram you
+replaced, or an index you have never opened. That breadth is deliberate: a
+freshness claim that cannot see the ledger is not a freshness claim. The
+website's lock was fixed for exactly this once already, after deleting a
+denial's four lines republished the document with the committed lock still
+validating; ingest had the same hole, found by review before anyone hit it.
+
 ## What a generation is
 
 Each ingest builds a **fresh generation** — invisible until activated — and
@@ -106,17 +124,19 @@ An empty `nodes` array means nothing was published — the ingest did not run, o
 ran without `--flip`. Then search for a phrase you know is in the record and
 check the hits carry `provenance.stable_id` and `generation`.
 
-**`provenance.stable_id` is also how you name a document to `takedown`.** For
-most documents it is `knowledge/<path-without-.md>`; a search result is the
-reliable way to read one off rather than guessing.
+**`provenance.stable_id` is also how you name a document to `takedown`.** It is
+`knowledge/<path-without-.md>` — always, since path is identity and nothing
+overrides it — and a search result is still the reliable way to read one off
+rather than typing it from memory.
 
 ## Where ingest runs — not on the host
 
 Ingest is a long job. It embeds every new chunk through the provider, and that
 is bounded by the provider's throughput rather than by anything ksor does.
 
-**Measured:** an 81-document book — 6,963 chunks — took **about 50 minutes**
-against a remote Postgres on a first, cold ingest with nothing to carry forward.
+**Measured 2026-08-23:** an 81-document book — 6,963 chunks — took **about 50
+minutes** against a remote Postgres on a first, cold ingest with nothing to
+carry forward. Not re-measured since.
 
 Compare that with the request timeouts of the platforms people reach for first:
 a serverless function caps out in the region of 300–800 seconds depending on
@@ -148,7 +168,8 @@ If your provider offers both a **pooled** and a **direct** endpoint (Neon's
 `-pooler` host, or port 6432), use whichever it gives you. ksor detects which and
 says so at boot, but the line is informational — it classifies, it never
 transforms, and the hazard it descends from cannot arise here. The 6,963-chunk
-ingest measured above ran through a pooled endpoint without incident. Reach for
+ingest measured above (2026-08-23) ran through a pooled endpoint without
+incident. Reach for
 the direct endpoint only if you actually hit pooler connection limits.
 
 ## Turning the abstention gate on
@@ -161,14 +182,24 @@ measure until the corpus is in there.
 pnpm exec ksor calibrate --instance instance.md
 ```
 
-It prints a recommended `vector_floor`. Paste it into **`instance.md`** with the
-date you measured it, then restart `ksor serve` — the floor is read at boot:
+It ends with a block to paste into **`instance.md`**'s frontmatter, exactly as
+printed — the floor, the measurement recorded beside it as a comment, and
+`floor_digest`, the digest of the retrieval predicate the floor was measured
+through. Paste it, then restart `ksor serve`: the floor is read at boot.
 
 ```yaml
 retrieval:
-  vector_floor: 0.55 # measured by ksor calibrate on 2026-08-23
+  vector_floor: 0.55 # calibrated 2026-08-23 on generation 3, model gemini-embedding-001/d1536, door: synthesized
+  floor_digest: 8bfb07d0e6f5
 ```
 
+If the file already declares `retrieval:`, merge the keys into the block it has
+rather than adding a second one — a duplicate key is refused.
+
+A measurement that does not separate in-corpus from out-of-corpus prints **no
+floor at all**, and a `vector_floor: uncalibrated` block instead. That block is
+the fail-closed state: every serve refuses until a real number replaces it.
+
 Until you do, `/health` reports the gate as `OFF (no floor declared — will not
 refuse out-of-corpus questions)` and every search envelope carries
 `gate: "off"`. That is honest absence, and an agent reading the envelope knows
@@ -186,11 +217,13 @@ correctly stays uncalibrated.
 
 ## Withdrawing a document
 
-A takedown is a row, not a file, so it reaches the door immediately:
+A takedown is a committed ledger entry FIRST and a database row second, written
+in one act — so it reaches the door immediately and the site at its next build,
+and a record with no database can still withdraw a document:
 
 ```sh
 pnpm exec ksor takedown --instance instance.md <stable-id> \
-  --reason "legal request 2026-08" --actor "j.smith"
+  --reason "legal request 2026-08" --actor human:j.smith
 ```
 
 `--actor` is required, and there is no default. A name taken from the
@@ -198,8 +231,23 @@ environment reads like a person and is whatever the shell happened to be
 (`runner` under CI, `root` in a container) — worse than no name at all in the
 one row that exists to record who did this.
 
-**The site stops at its next build.** It reads `.ksor-denylist.json`, which
-`pnpm build` refreshes via `pnpm export-denylist`. So after a takedown, rebuild
-and redeploy the site, or the human surface keeps publishing what the agent
-surface already refuses. See [deploying.md](./deploying.md) for why that build
-needs `KSOR_DB_URL`.
+Two things the actor must satisfy, both refused before any database is touched.
+It must be a well-formed actor — `human:<handle>` or `process:<id>`, never a
+bare name (`ksor-actor-form`) and never a `team:` (a team cannot perform an
+act). And `takedown_authorities` in `.ksor/governance.yaml` must name it
+(`ksor-takedown-unauthorised`); the same check runs over every entry in the
+ledger at `pnpm check`, `ksor build` and ingest, so a line appended by hand in a
+pull request is refused exactly as the verb would refuse it.
+
+Lifting a takedown is `--revoke <entry-id>` — the id of the LEDGER ENTRY, not
+the stable id. The denial that created it prints the id, `ksor takedown
+--ledger` lists it, and it is written in `.ksor/takedowns.yaml`; none of the
+three needs a database, because the ledger is a file in the repository. The
+ledger is append-only: a revocation is a new entry, never a deleted line, and a
+build whose ledger shrank against its own git history is refused.
+
+**The site stops at its next build.** It reads the committed ledger
+(`.ksor/takedowns.yaml`), so after a takedown, merge the entry, rebuild and
+redeploy the site, or the human surface keeps publishing what the agent
+surface already refuses. The site needs no database for this: the
+ledger is a file in the repository, and the site build reads it.