@konneal/engine 0.1.0

package/docs/konneal-extraction-plan.md

@@ -0,0 +1,481 @@
+# The Konneal extraction plan — packages, phases, end-state
+
+> Status: PLAN v4 (2026-09-13) — adds the multi-cloud posture (§5
+> ports and adapters, §6 state management, §7 the software/infrastructure
+> split). v3's boundary — Konneal is the backend: build pipeline + API
+> plane — is redrawn: **Konneal is
+> the backend** — the build pipeline and the API plane — and nothing
+> else. The user plane (interface, site shell, articles, branding)
+> belongs wholly to the publisher. The shareable surface between them
+> is the documented API plus one small package: `@konneal/client`, the
+> API types, the streaming client and the contract-bound renderers
+> (typed blocks, citations, the in-context document pane). v3 keeps the
+> v2 guarantees — content build first-class (§2.1), real customization
+> (§2.2, now by ownership rather than theming), publisher-owned
+> Cloudflare topology (§2.3) — and simplifies the extraction
+> accordingly. Extends docs/multi-sdo-architecture.md §7 (whose
+> step 1, the profile extraction, is shipped) into the full package
+> topology and the phased extraction. The discipline is the one this
+> codebase already keeps: every phase lands with zero behavior change,
+> the drift and contract tests green, and the promotion gates passing
+> against production.
+
+## 1. The principle that shapes everything
+
+Two facts decide the package boundaries:
+
+1. **The wire contract is two-sided and must never split.** The chunk
+   wire type (`workers/shared/chunk.ts`) and the producer-side adapter
+   (`ingest/vector_adapter.py`) are two expressions of one contract,
+   held together today by a contract test. They live or break together,
+   so the serving workers and the ingest CLI ship from ONE repository,
+   versioned in lockstep.
+2. **A deployment is configuration, branding and content — nothing
+   else.** The end-state of `oimlsmart/ai` (the OIML deployment) is a
+   profile, a theme, article content, deployment config, and pinned
+   references to the content that already lives in its own repositories
+   (the corpora, the bibliography, the terminology, the models). "Data
+   elsewhere" is already true at the content level; the extraction
+   finishes the job at the code level.
+
+## 2. The package topology
+
+```
+konneal/engine                      (the monorepo — one version train)
+├── packages/engine-workers/       @konneal/engine      (npm)
+│     routes table, ask pipeline, stages, verdict engine, absence,
+│     verify, research, auth relying-party, quota, admin ops
+├── packages/client/               @konneal/client      (npm)
+│     the API types, the SSE client, and the contract-bound
+│     renderers (typed blocks, citations, the document pane)
+├── packages/profile-schema/       @konneal/profile     (npm)
+│     the profile schema, codegen, drift guard
+├── ingest/                        konneal-ingest       (PyPI)
+│     parse/chunk/embed/upsert/enrich/replay/reconcile/restore +
+│     the wire adapter (reads profile/*.yaml directly)
+├── harness/                                            (in-repo tooling)
+│     the eval runners (grade/golden/annealment/variance/ui) —
+│     content-neutral; suites come from a profile
+└── docs/                                               
+      spec-pipeline, spec-api, INGEST-ARCHITECTURE, sota-mechanisms,
+      multi-sdo-architecture
+
+konneal/konneal.github.io           the product site (exists)
+konneal/create-publisher            template repo (later, phase D):
+                                   npm create @konneal/publisher —
+                                   profile skeleton + wrangler + CI
+
+oimlsmart/ai                        becomes publisher-oiml (reference)
+├── profile/        publisher.yaml, datasets.yaml, corpora.yaml,
+│                   sources.yaml (pinned refs to the content repos),
+│                   evals/ (golden + annealment suites — OIML content),
+│                   prompts.yaml (voice vars + rare overrides),
+│                   codec: oiml-pubid
+├── theme/          logo, colors, fonts, nav labels
+├── site/           the ENTIRE user plane, unchanged: the chat app,
+│                   the articles (MDX), the annealment panel, branding,
+│                   the site shell — consuming @konneal/client for the
+│                   contract components
+├── deploy/         wrangler.toml(s) — bindings, vars, INDEX_VERSION —
+│                   and the thin deploy wrapper
+├── whitepaper/     OIML's academic artifact (content, stays)
+├── .github/        CI: profile validation + engine-pinned gates
+└── workers/src/    ENTRY ONLY (~10 lines: createWorker({ profile }))
+```
+
+### 2.1 The content build path (Metanorma and Primmel stay first-class)
+
+The build that turns a publisher's Metanorma corpus and Primmel
+packages into a serving index is engine machinery driven by
+profile-declared sources. The engine CLI gains one orchestration
+command:
+
+```
+konneal build --profile profile/
+```
+
+It reads `profile/sources.yaml` — the pinned references to the
+publisher's Metanorma corpora (clean and recovered), relaton
+bibliography, Glossarist terminology, and Primmel packages checkout —
+and runs the derivation in the order the incidents taught, as
+structure rather than memory: parse (clean-beats-dirty precedence,
+shell flagging, language policy from the profile) → typed units from
+the Metanorma documents → the model plane from the Primmel projection
+(the freshness gate: a package's source hash moves, the build fails
+until re-indexed) → terminology and graph ingestion → embed → upsert →
+restore gaps → enrichment replay → reconcile against the canonical
+declaration → unit assets → rendered documents → the answer-cache
+generation stamp. The sequence mistakes that caused the 2026-09-09/10/11
+incidents become impossible for every SDO, not just this one.
+
+The build stamps the index with a wire version alongside the existing
+index version, so a deployment never serves an index built by an
+ingest version its serving engine cannot read — the freshness
+mechanism extended from content drift to engine drift.
+
+### 2.2 The interface (owned by the publisher, served by contract)
+
+The publisher owns the entire user plane: the chat application, the
+article pages, the site shell of their choosing, the branding, the
+annealment panel, the whitepaper surface. Nothing about their frontend
+waits on an engine release, and nothing about the engine carries their
+taste. OIML's site stays exactly where it is, in the deployment
+repository, including the site-shell dependency it already uses.
+
+Two things cross the boundary, and only two:
+
+1. **The documented API** (spec-api.md): ask and search, absence and
+   verification, research, sessions, projects and memory files,
+   datasets, auth, administration, and the MCP servers. The UI already
+   speaks it over HTTP and server-sent events, and the UI test suite
+   already runs against stubbed APIs — the seam exists and is proven.
+   The memory and project features are backend features: the engine
+   owns the D1 schema and CRUD; the publisher's frontend renders them.
+2. **`@konneal/client`** — a small npm package extracted from the
+   current site: the API types, the streaming client, and the
+   contract-bound renderers (formula/table/figure/verdict blocks,
+   citation chips, the in-context document pane). Renderers of the
+   answer contract ship with the contract, so block rendering cannot
+   fork and drift from the wire types; pages, layout and everything
+   else stay publisher code consuming them.
+
+For the second SDO, the Konneal org ships a **forkable UI starter** —
+`konneal/ui-starter`, seeded from OIML's site at extraction and kept
+as a template to copy, not a dependency to pin. Fork-not-depend is the
+honest model for frontends.
+
+Backend customization still composes, because publisher logic is not
+only frontend: the OIML-CS application-draft acts are ask-path
+behavior. The worker entry stays composable —
+
+```ts
+createWorker({ profile, hooks: { acts: oimlDraftActs }, extraRoutes })
+```
+
+— with custom routes reusing the engine's handlers and auth, and the
+draft-act branch moving out of the engine's ask path into OIML's hook.
+
+### 2.3 The Cloudflare topology (bindings are the publisher's facts)
+
+Wrangler configuration, bindings, secrets and accounts stay in the
+deployment repository untouched — Vectorize indexes, D1, KV, R2,
+Queues, the OIDC issuer are per-publisher facts declared by the
+profile's audiences (the two-index isolation pattern generalizes: one
+index per audience, and the binding lint enforces it against the
+profile's declarations, not a hardcoded list). The engine provides two
+thin commands the deployment wraps: `konneal bootstrap` (create the
+declared indexes/buckets/namespaces, patch ids into wrangler) and
+`konneal deploy` (today's guarded deploy — branch and tree checks,
+version bump, settle, profile-sourced smoke) so the operational
+discipline ships with the engine instead of being re-implemented per
+SDO.
+
+**The development loop while both repos live:** the deployment pins
+exact engine versions in its lockfile, with a `file:` override for
+local engine work — the same pattern this repo already uses for the
+site shell. Engine PRs run the engine's fixture matrix; the deployment
+CI runs its own gates on the pinned version; neither blocks the other
+until a release is deliberately adopted.
+
+**Versioning.** The engine releases semver from `konneal/engine`; a
+deployment pins exact versions (the same deliberateness as any
+dependency). The wire contract, the UI and the workers share the
+monorepo's version because they share its review. Content drift is
+already governed by the freshness gate (`source_hash`); engine drift
+joins it in the deployment's lockfile.
+
+**Why npm/PyPI rather than submodules or a template-only engine.**
+Cloudflare Workers bundle from `node_modules` as a matter of course; a
+real package gives SDOs version pinning, changelogs and upgrade
+paths — the governance the architecture doc named as an open question,
+answered mechanically.
+
+## 3. The remaining publisher facts (the audit delta)
+
+Found since the architecture doc; each moves in the phase shown:
+
+| Fact | Today | Moves to | Phase |
+|---|---|---|---|
+| Identifier grammar | OIML patterns in `upload_documents.py` + site `docSlug` | profile `codec: oiml-pubid`; engine carries the codec registry | A |
+| Prompt voice | `prompts/system.md` names OIML and the corpus shape | template vars + `profile/prompts.yaml` | A |
+| Eval suites | `tests/golden/*` (OIML questions) | `profile/evals/`; harness reads the profile path | A |
+| Annealment panel data | `site/src/chat/annealmentLadder.ts` | `profile/evals/` (it IS the measured ladder) | A |
+| Process expansion terms | `THRESHOLDS.processExpansion` (OIML-CS/CASCO words) | profile dataset note / expansion list | A |
+| Smoke queries | OIML questions in `deploy.sh` | `profile/evals/smoke` | A |
+| Models table (site) | hardcoded in how-it-works | profile (publisher's model policy disclosure) | A |
+| Glossary/relaton/graph sources | ingest config paths | `profile/sources.yaml` (pinned refs) | A |
+
+## 4. The phases (each independently shippable, gates green)
+
+**Phase A — generalize in place** (in `oimlsmart/ai`, zero behavior
+change): everything in §3, the codec registry (the OIML codec wraps the
+pubid library; a plain-slug codec proves genericity), prompt
+templates, evals-to-profile with the harness reading the declared path,
+the profile codegen extended to feed the site. The repo is now
+*conceptually* a profile + engine, with the engine still physically
+inside it.
+
+**Phase B — the engine is born** (`konneal/engine`): move the code with
+its history (`git filter-repo` per subtree, so archaeology survives —
+blame for the 40017 fix must still point at the 40017 incident);
+establish the monorepo workspaces, the npm/PyPI packaging, the engine's
+own CI running the harness against a fixture corpus. `oimlsmart/ai`
+keeps running unchanged in parallel.
+
+**Phase C — the consumer flip**: `oimlsmart/ai` depends on
+`@konneal/engine@x.y.z`; `workers/` shrinks to the entry; `ingest/` and
+the heavy `scripts/` become dependencies and thin wrappers; CI re-points;
+the full promotion gate runs against production before the flip is
+declared done. Nothing about the deployment's operations changes —
+same wrangler, same bindings, same deploy flow.
+
+**Phase D — the ecosystem**: the forkable `konneal/ui-starter` seeded
+from OIML's site, `create-publisher` scaffolding, the reference matrix
+in engine CI (this profile as fixture #1, a second fixture from
+another Metanorma flavor), the product site build in
+`konneal.github.io`, and the public flip of the repos at launch.
+
+The backend-only boundary shrinks the extraction itself: Phase B moves
+the workers, ingest, harness and docs — never the site; the client
+package is extracted from the site in Phase C, with the site's
+remaining local copies deleted behind a one-release deprecation so the
+flip is a lockfile change, not a rewrite. The UI test suite stays in
+the deployment repo (it tests the deployment's frontend); the engine's
+CI tests the API plane, which the golden and annealment runners
+already exercise over HTTP.
+
+## 5. Invariants that make each phase safe
+
+- The profile drift test (YAML ≡ codegen) — exists.
+- The TS↔py wire contract test — exists, moves with the contract.
+- The promotion gates (golden ×3 + annealment ×6) — run at every phase
+  boundary against production.
+- The deploy version guard and smoke (now retry-hardened) — unchanged.
+- The binding-isolation lint — moves with the workers, runs in engine
+  CI against the fixture profile.
+
+## 6. Honest risks, named
+
+- **Workers-from-npm ergonomics**: standard wrangler bundling; verified
+  in phase B before the flip, with the current repo as fallback the
+  whole time.
+- **Contract-renderer drift**: eliminated where it matters — the
+  block renderers ship in `@konneal/client` with the types; the
+  publisher's pages cannot fork the contract even though they own the
+  frontend. The residual risk is an SDO ignoring the client package in
+  a bespoke frontend; the API docs and the MCP surface keep the wire
+  honest regardless.
+- **History preservation**: filter-repo per subtree; the reference
+  READMEs cross-link so the archaeology stays reachable from both
+  repos.
+- **The whitepaper and articles are OIML's**, not the engine's — they
+  stay in the publisher repo; the engine's docs describe mechanisms,
+  never this publisher.
+- **Trademark screening** remains the gating step before any public
+  Konneal marketing; the repos stay private until it clears.
+
+## 5. Ports and adapters — the multi-cloud posture
+
+The engine's domain logic is portable software; infrastructure appears
+only behind narrow ports, each with one reference adapter (Cloudflare,
+because it is proven in production) and a conformance suite. Additional
+adapters are contributed against the suite when a real deployment
+demands them — never speculatively.
+
+| Port | Semantics the engine requires | Reference adapter | Other adapters (on demand) |
+|---|---|---|---|
+| `ModelRunner` | run(role, kind, payload, {effort, budget, sampling}); streaming for answers | Workers AI binding | any OpenAI-compatible HTTP endpoint (covers most clouds, gateways and self-hosting; the z.ai vision lane already runs over HTTP — the precedent), Ollama/local |
+| `VectorIndex` | dense query with metadata filters, upsert, getByIds, delete; the scalar-or-string-array metadata law is the PORT contract | Vectorize | pgvector (the universal default), Qdrant, Weaviate, OpenSearch |
+| `Store` | the repositories: documents registry, model plane, unit payloads, sessions, conversations, projects, memory files, API keys, telemetry | D1 (SQLite) | libsql/Turso, Postgres, MySQL |
+| `Kv` | get/put with TTL on the hot read path | Workers KV | Redis (ubiquitous), DynamoDB, in-memory |
+| `Blobs` | put/get/delete immutable objects | R2 | any S3-compatible endpoint — R2 already speaks S3 |
+| `Runtime` | background work after response (waitUntil) | Workers | the Node/Bun equivalents |
+| Optional: `BotCheck` | human verification for the anonymous tier | Turnstile | hCaptcha, none |
+
+Design rules that keep the ports honest:
+
+- **Lexical search stays in the engine.** Vectorize has no sparse
+  vectors, so the lexical lane already runs engine-side over the
+  relational store. Adapters therefore need only dense search plus
+  filters — the weakest common denominator — and richer backends are a
+  superset, never a requirement.
+- **Model policy is deployment data, quirks are adapter facts.** Which
+  model serves which role is already configuration (`MODELS` +
+  `roleModel` overrides); provider-specific call shaping (the GLM
+  effort-budget rule, provider message-shape limits) lives inside the
+  adapter and is documented with it.
+- **Port purity is linted.** Domain modules import ports, never
+  adapters; the binding lint grows into this check, so an
+  infrastructure API cannot leak back into the stages.
+- **The conformance suites are the contract.** The wire law (already
+  tested TS↔Python), repository behavior, KV semantics and a
+  model round-trip each become suites every adapter must pass — the
+  same discipline the profile drift test applies to configuration.
+
+**The reference path is zero-configuration.** A Cloudflare deployment
+declares no adapters file and no model policy of its own: the engine
+defaults to the Cloudflare reference adapters, wiring them from
+wrangler.toml's bindings exactly as today, and ships the reference
+model policy (with the `roleModel`/effort environment overrides that
+already exist). Adapter and model-policy configuration appears in a
+deployment repository only when that deployment deviates from the
+reference — which the reference deployment never does. The multi-cloud
+machinery is invisible unless invoked; ai.oimlsmart.org carries none
+of it.
+
+**Phasing stance — ports as seams, adapters on demand.** Phases A–C
+proceed Cloudflare-flavored exactly as planned; Phase B introduces the
+port boundaries as interfaces with the Cloudflare adapter as the sole
+implementation. The engine becomes adapter-shaped without paying for a
+second adapter. When a concrete SDO requires another cloud, the work
+is implementing adapters against existing conformance suites plus
+their infrastructure configuration — a focused contribution, not a
+rewrite, because the seams already exist.
+
+## 6. State management — the taxonomy that answers migration
+
+Every piece of state is classified, and the class determines its
+multi-cloud story:
+
+| Class | Contents | Multi-cloud story |
+|---|---|---|
+| **Rebuildable** (derived corpus) | vector indexes, unit payloads, model-plane nodes, rendered documents, unit assets | **Rebuild, never migrate.** The derivation pipeline is the chain of custody: pinned sources → `konneal build` → state. Moving clouds is re-running the build against the new target; the canonical-set declaration and reconciliation verify the result. This is the dividend of "data elsewhere". |
+| **Live** (user and tenant state) | sessions, conversations, projects, memory files, API keys | **Export/import through the ports.** `konneal state export|import` walks the repositories; portable precisely because the repositories are ported. |
+| **Ephemeral** (by design) | answer caches (exact + semantic), enrichment contexts, quota counters | **No migration.** TTLs and the corpus-generation stamp already treat this state as disposable; a new deployment cold-starts and converges within the TTL window (quota counters accept a day-boundary reset — documented, not hidden). |
+| **Analytics** | query and spend telemetry | **Export or cut over** — append-only rows; the deployment chooses import-for-continuity or a clean cutover. |
+
+Secrets, bindings and domains are infrastructure configuration in the
+deployment repository and never migrate through the engine at all.
+
+## 7. Software versus infrastructure — the split, stated as law
+
+- **Software (the engine ships it):** the retrieval stages and scoring,
+  the answer contract and its enforcement, the verdict engine, the
+  build derivation and its invariants, the evaluation harness, the
+  profile system, the HTTP route table and API surface, the OIDC
+  relying-party logic, quota and cache semantics, the port definitions,
+  the Cloudflare adapters, and the conformance suites. None of it knows
+  an account id, a binding name or a provider catalog.
+- **Infrastructure (the deployment declares it):** the choice and
+  configuration of adapters, bindings, accounts and credentials, the
+  model policy (which concrete models serve which roles, at what
+  pricing), capacity and limits, scheduling, domains and CDN.
+- **The law:** infrastructure appears in the engine only behind a
+  port, one reference adapter per port, conformance-tested. The
+  current codebase is already close: the ingest CLI speaks provider
+  REST through one class, the restore/replay tools proved both binding
+  and HTTP lanes for the same operations, and every provider gotcha
+  (getByIds above twenty, the metadata law, the effort-budget rule) is
+  already documented as a fact rather than scattered as folklore. The
+  extraction formalizes what the incidents already taught.
+
+## 8. Worked examples — the full stack on AWS or Azure
+
+What follows is what a deployment actually configures on a full-stack
+hyperscaler, and what stays untouched in the engine. The profile is
+identical on every cloud; only the adapter wiring and infrastructure
+configuration differ.
+
+### 8.1 The per-port mapping
+
+| Port | AWS | Azure |
+|---|---|---|
+| Compute for the API plane | containers (ECS Fargate / App Runner) behind ALB or API Gateway | Container Apps / App Service / Functions |
+| `ModelRunner` | Bedrock models, or self-hosted open-weight models on EC2/SageMaker behind an OpenAI-compatible endpoint (vLLM) | Azure AI Foundry endpoints (OpenAI-compatible), or the same self-hosted lane |
+| `VectorIndex` | pgvector on Aurora/RDS Postgres (or OpenSearch) | pgvector on Azure Database for PostgreSQL (or Azure AI Search — a superset: vectors, filters and BM25) |
+| `Store` | Aurora/RDS Postgres | Azure Database for PostgreSQL |
+| `Kv` | ElastiCache Redis | Azure Cache for Redis |
+| `Blobs` | S3 | Azure Blob Storage (S3-interop or a thin adapter) |
+| `Runtime` (waitUntil) | the container adapter (no isolate limits) | same |
+| Scheduling | EventBridge Scheduler → the engine's `/admin/tick` route | a scheduled job → the same route |
+| `BotCheck` | Turnstile — a cloud-neutral web service, unchanged | unchanged |
+
+### 8.2 What the SDO configures (the deployment repository)
+
+```
+publisher-deployment/
+├── profile/            # IDENTICAL on every cloud: publisher, datasets,
+│                       # corpora, evals, sources.yaml (pinned content
+│                       # refs), prompts, codec
+├── adapters.yaml       # the port→implementation choice + endpoints:
+│                       # vector: pgvector(postgres-url), store: postgres,
+│                       # kv: redis, blobs: s3, models: openai-compatible(base-url)
+├── model-policy.yaml   # role→model mapping over THIS cloud's catalog,
+│                       # with pricing and the per-family call rules
+├── infra/              # Terraform/CDK/Bicep: the database, Redis, the
+│                       # bucket, DNS/CDN, secrets, the container service,
+│                       # the scheduler — the cloud's own language
+├── deploy/             # pipeline: build the container, deploy,
+│                       # konneal bootstrap (schema + index declaration),
+│                       # konneal build, konneal deploy (guards + smoke)
+└── CI                  # profile validation + engine-pinned gates,
+                        # exactly as on Cloudflare
+```
+
+`konneal bootstrap` and `konneal build` run the same code everywhere:
+bootstrap applies the repository schema and the index declaration
+through the chosen adapters; build reads `profile/sources.yaml` and
+runs the derivation into the declared state.
+
+### 8.3 What remains platform-independent (in Konneal)
+
+All of the domain, unchanged and untested-differently per cloud: the
+retrieval stages and scoring, the answer contract and its enforcement,
+the verdict engine, provable absence, verification, the research loop,
+sessions/projects/memory-file logic, quota and cache semantics, the
+build derivation and its invariants (canonical set, wire law, replay),
+the evaluation harness and grading semantics, the profile system, the
+HTTP route table and API surface, the MCP servers, `@konneal/client`,
+the port definitions, the conformance suites, and the Cloudflare
+reference adapters.
+
+### 8.4 The honest deltas
+
+1. **Model catalogs differ — the one real delta.** The reference cost
+   policy rides Cloudflare's open-weight catalog. A hyperscaler
+   deployment either maps roles onto that cloud's catalog in
+   `model-policy.yaml`, or keeps the exact policy by serving the same
+   open-weight models itself behind an OpenAI-compatible endpoint —
+   the adapter makes self-hosting a first-class lane, which is the
+   documented fallback posture already.
+2. **The execution model loosens, not tightens.** Containers have none
+   of the isolate limits (subrequest counts, topK caps) the engine
+   already respects; the engine asks every adapter for the weakest
+   common denominator, so nothing breaks and richer backends are a
+   bonus.
+3. **Deploy tooling is the cloud's own.** Wrangler is Cloudflare's;
+   AWS and Azure deployments carry Terraform/CDK/Bicep in `infra/`.
+   The guarded deploy semantics (version discipline, smoke, gates) are
+   engine commands and travel intact.
+4. **Dialect and behavior drift** across relational backends is the
+   conformance suites' job — an adapter ships only when the repository
+   suite passes against it.
+
+## 9. Impact on the reference deployment (ai.oimlsmart.org)
+
+**At runtime: nothing changes, at any phase.** Phases A–C are
+behavior-preserving by construction — the port interfaces erase at
+runtime, the adapters call the exact same bindings, and every phase
+boundary runs the full promotion gate against production before it is
+declared done. The infrastructure, the models, the index, the caches
+and the operational loop (build, reconcile, replay, deploy guards,
+gates) are untouched.
+
+**The one-time transition cost (Phase C):** the workers directory
+shrinks to a ~10-line entry, the engine arrives as a pinned package,
+and the flip deploys behind the standing gate protocol with instant
+rollback to the previous worker version. After the flip, the
+deployment repository contains only: the profile (which is the
+publisher's own data, half-extracted already), the theme, the entire
+user plane (unchanged), wrangler configuration (unchanged), the entry,
+the whitepaper and CI. The repository gets smaller, not bigger, and
+the deploy command remains what it is today.
+
+**The new discipline — and why it is a net reduction of concern:**
+engine upgrades arrive as deliberate version bumps instead of
+entangled commits, the port-purity lint prevents infrastructure
+leakage regressions for everyone including this deployment, and the
+conformance suites hold the behavior the reference deployment depends
+on. The configuration surface that other clouds require (adapters,
+model policy, infrastructure code) never exists here, because the
+reference is the default.