Anchor Keel v1.0 — release notes

Anchor Keel is a data platform: a shared core that connects to your databases and works out what the data means, and licensed modules that put that understanding to work (ADR-0021). Everything it infers is a proposal with evidence and a confidence score until a person accepts it.

• Shared core — connectors for eight engines (directly or through a private agent), metadata harvesting and bounded profiling, evidence-based inference, governance (glossary, ownership, data quality and trust, access policies, certification, lineage, hash-chained audit), drift detection and notifications, multi-tenancy with row-level security, SSO (OIDC) and the web app.
• Keel Semantic (the launch module) — a governed semantic model proposed from the schemas, reviewed by people and versioned like code, served as the same metrics to BI tools, apps and AI agents (semantic query API, MCP server, SQL interface beta, in-app assistant), with exports and imports.
• Keel Migrate (licensed per tenant, M10–M11) — plan & prove: mappings with evidence, generated dbt/SQL and reconciliation with sign-off, all read-only; run & cut over: the private agent loads and syncs the target inside your network with a separate, scope-checked write credential, then a guided cutover with instant rollback.

Keel is read-only by default: it writes to customer systems only in the Migrate write plane. Customer rows are not stored: profiling keeps statistics, and migrations move rows inside your network while Keel receives counts, checksums and keys only. Everything governed is audited.

v1.0 is the result of ten milestones (M0–M9); the marketing site (MS) and Keel Migrate (M10, M11) followed. "Anchor Keel" is a working product name.

Highlights

Shared core

• Eight read-only connectors — PostgreSQL, SQL Server / Azure SQL, MySQL / MariaDB, Oracle, Amazon Redshift, Snowflake (key pair or password), Google BigQuery (service account, cost guard) and Databricks SQL (PAT or OAuth M2M), directly or through a private agent in your network that pulls work over outbound HTTPS.
• Evidence-backed inference — relationships, table roles, grains, semantic types and PII, each a proposal with confidence and evidence; optional LLM assistance that only ever proposes. Heuristics-only precision 1.00 on the Chinook, Northwind, AdventureWorksLT and AdventureWorksDW benchmarks.
• Governance — glossary with synonyms and domains, ownership, data-quality rules with scorecards, incidents and metric trust scores, access policies (masks, row filters, deny) with a simulator, certification with criteria and expiry, column-level lineage and impact analysis, a hash-chained audit log with nightly verification.
• Staying in sync — scheduled drift scans with rename detection and automatic fix branches; in-app, email, Slack, Teams and HMAC-signed webhook notifications.
• Platform — tenants and workspaces with six roles, PostgreSQL row-level security on every tenant table, OIDC sign-in, API keys; licensed modules granted per tenant by the operator.

Keel Semantic

• Model generation and a strategy report — a generated model on a proposals branch with a change request, and a recommendation among four delivery patterns with readiness and next actions.
• Git-like lifecycle — branches, object-level diffs, change requests with validation / breaking-change / data-quality / governance checks, three-way merges and SemVer releases with rollback.
• Model workspace — a graph canvas for 1,000+ entities, inspector editing, YAML code view, SQL preview, autosaved private working copies.
• Query compiler — fan-trap-safe SQL for all eight dialects, every value parameterized, access policies compiled in, byte-identical SQL per release, ~3 ms p95 compile time on a 500-entity model.
• Serving — semantic query API endpoints with API keys, caching and rate limits; an MCP server per endpoint for AI agents (no raw SQL); an in-app assistant that cites the metrics it used; a PostgreSQL-wire SQL interface (v1.1 beta, feature flag); exports to dbt MetricFlow, Cube, LookML, Power BI (TMDL) and open YAML with Git (GitHub) delivery, and imports from dbt, LookML and Cube.

Keel Migrate (licensed)

• Plan & prove (F18) — proposed table and column mappings, transforms and code maps with evidence; immutable plan versions with approval; dbt projects and idempotent SQL in eight dialects as a zip or a Git pull request; reconciliation (row counts, keys, cross-engine checksums, totals) that blocks sign-off until every Critical check passes or has a recorded exception. Keel issues only read-only queries in this phase.
• Run & cut over (F19) — the private agent bulk-loads through a staging schema (resumable, poison rows quarantined) and keeps the target in sync with change data capture; a separate write credential is scope-checked; a guided, audited cutover with an optional four-eyes approval switches Keel's models and serving endpoints to the target, with rollback in well under a minute.

By milestone

M0 — Foundation

Modular monolith (eight modules × Domain / Application / Infrastructure / Contracts) with Clean Architecture enforced by architecture tests; Result-based error handling; source-generated Mediator with logging, tenant, authorization, validation, idempotency and unit-of-work behaviours; PostgreSQL job queue with transactional outbox; RFC 9457 Problem Details; OpenAPI 3.1 contract snapshot-tested; .NET Aspire local stack; OpenTelemetry; React 19 SPA shell built to the approved prototype with light and dark themes.

M1 — Identity and tenancy (F01)

Tenants, workspaces, six roles (Owner tenant-wide), invitations, API keys (keel_live_…, hashed, scoped, revocable within 60 s); OIDC sign-in (Keycloak in development); PostgreSQL row-level security on every tenant table with a non-bypassing runtime role; cross-tenant access answers 404 and is audited; audit log core (append-only, hash-chained); onboarding, members, API keys and AI & privacy settings.

M2 — Sources, harvesting, profiling (F02, F03)

Connector abstractions and conformance suite; PostgreSQL and SQL Server connectors; secret store (envelope encryption, Azure Key Vault adapter); SSRF guard; worker-run Test connection with a pass/warn/fail checklist and read-only role scripts; discovery runs (harvest → profile) with live progress over SSE, cancel and resume; bounded, privacy-preserving profiling; Sources, Connect sheet, Discovery explorer and Home screens; Chinook sample databases.

M3 — Inference (F04, F05)

Relationship scoring with evidence, classification of tables and columns, sensitivity and PII detection; optional LLM gateway (Anthropic, structured output, budgets, caching) that falls back to heuristics; proposals that survive rescans; the Review queue with evidence panel, bulk accept and undo; accuracy benchmarks in CI.

M4 — Model generation, versioning, strategy (F06, F08)

The versioned model document (canonical JSON, content hash), validator, diff and three-way merge; branches, change requests with checks, releases and rollback; automatic generation after each scan; strategy engine and report; Change request and Strategy screens.

M5 — Model workspace and compiler core (F07, F13)

Graph canvas (xyflow + ELK) with levels of detail for 1,000 entities; inspector editing, undo/redo, YAML round trip, SQL preview, private working copies with autosave and rebase; query compiler for PostgreSQL and SQL Server with golden tests, injection fuzzing and the fan-trap proof; Query Playground.

M6 — Glossary, data quality, audit (F09, F10, F16)

Glossary terms, synonyms, domains, ownership, suggestions, import/export and search; data-quality rules (suggested and custom SQL), scheduled runs, scorecards, volume anomaly detection, incidents and metric trust scores; audit chain verification, retention and export; in-app inbox, email and daily digest.

M7 — Policies, lineage, serving, drift (F11, F12, F13, F16)

Access policies enforced in the compiler for every consumer, with a simulator and a default mask suggestion; certification with configurable criteria and expiry; serving endpoints with API keys, Redis cache keyed by effective policy, rate limits and a metadata-only query log; column-level lineage (view parsing, OpenLineage, dbt manifests) and impact analysis; drift scans with rename fixes; Slack, Teams and signed webhook channels.

M8 — AI and ecosystem (F14, F15, F02)

MCP server per serving endpoint (six tools, two resources, API key or OAuth); in-app assistant with a bounded tool loop, citations and draft-metric proposals; a 100-question evaluation set with a nightly workflow; exporters for dbt MetricFlow, Cube, LookML, Power BI TMDL and open YAML with reports, history, Git push and auto-export, plus a dbt importer proven by round trip; MySQL, Oracle, Redshift, Snowflake, BigQuery and Databricks connectors and dialects (ADR-0014, ADR-0015).

M9 — Hardening and enterprise

• Product documentation site (docs-site/, VitePress, ADR-0019) with generated API, permission, error-code and configuration references, built and link-checked in CI.
• A reproducible, idempotent demo seeder (scripts/seed-demo.sh / .ps1) that builds a complete governed demo tenant through the public API.
• Marketing-site handoff (docs/handoff/marketing-site.md), brand SVGs (design/brand/) and product screenshots (design/screenshots/, light and dark).
• Imports — dbt MetricFlow, LookML and Cube files (or a zip) become proposals (origin Imported, file:line evidence) on an import branch with a change request; objects main has differently are kept as conflicts the reviewer resolves per object on the change request page. dbt tests and Great Expectations suites become suggested data-quality rules on a source's scanned tables. Round trips Keel → dbt / LookML / Cube → Keel show no semantic diff for supported constructs.
• SQL interface (v1.1, feature flag sql-interface, ADR-0018) — Keel.SqlGateway speaks the PostgreSQL wire protocol on port 5433 (user = endpoint slug, password = API key with serving:query, TLS). Each endpoint appears as schema keel with a table per entity with metrics plus metrics; SELECT dims, SUM(metric) … WHERE … GROUP BY … ORDER BY … LIMIT becomes a semantic query on the governed serving path (policies, rate limits, cache, query log as consumer sql); pg_catalog / information_schema browsing for drivers and BI tools; per-tenant feature flags (Owners, Settings › Serving › Connect with SQL).
• Private agent (ADR-0006, ADR-0017): Settings › Agents (Owners/Admins) enrolls a Keel Agent with a one-time token and shows its docker run command once (deploy/agent/Dockerfile); the agent pins a self-signed ECDSA certificate, signs every request (mTLS in production) and pulls work over outbound HTTPS. Sources in Through a private agent mode name a secret held on the agent — Keel never receives it. Test connection, scans (harvest, profile, probes), quality rules and semantic queries (Playground, serving, MCP, assistant) run on the agent; only metadata, statistics, aggregates and requested rows come back, sanitized again server-side. Enroll and revoke are audited.
• Performance tuning, the security review and the accessibility audit are the other M9 tracks; see docs/milestones/M9-summary.md for what shipped.

MS — Marketing site (F17)

• Public site (site/, Astro + React islands, ADR-0020): home, pricing, security, demo request, legal and 404, built to the approved designs; consent-gated analytics; generated CSP; Lighthouse 100 on mobile; Cloudflare Pages previews and deploys. The production build refuses remaining [PLACEHOLDER] copy.
• Demo requests (POST /api/public/v1/demo-requests): Turnstile, honeypot, rate limits (5/h per IP, 20/day per domain), the IP stored only as a hash, 24-month retention, confirmation and sales emails, optional CRM webhook.

M10 — Keel Migrate: plan & prove (F18, licensed module)

• Licensed modules (ADR-0021): operators grant Migrate per tenant; unlicensed tenants don't see it.
• Map: Keel proposes table and column mappings, transforms and code maps from a source to a target (a data source, the semantic model, or uploaded DDL/dbt), with evidence and confidence, reviewed in the Mapping workbench.
• Generate: a dbt project and/or idempotent SQL scripts in eight target dialects, as a zip or a Git pull request, from an approved plan version. Keel never runs them.
• Prove: reconciliation compares row counts, keys, cross-engine checksums and totals on both sides with read-only queries, and blocks sign-off until every Critical check passes or has a recorded exception. Restricted columns keep their classification and get a proposed mask.

M11 — Keel Migrate: run & cut over (F19, licensed module)

• Keel runs the migration inside your network: the private agent bulk-copies the approved plan's tables (PostgreSQL COPY / SqlBulkCopy into a staging schema, resumable per chunk, poison rows quarantined, writes ordered by your foreign keys) and applies the generated SQL on the target. It keeps the target in sync with change data capture (SQL Server Change Tracking or CDC, PostgreSQL logical replication, or polling) until cutover.
• A separate write credential, held by the agent and scope-checked: a credential that can write outside the target and staging schemas is refused.
• Guided cutover: observed freeze, final sync to zero lag, final reconciliation (Critical checks gate the switch), an optional four-eyes approval, then Keel repoints its semantic models and serving endpoints to the target. One-click rollback swaps them back in well under a minute.
• Rows never reach Keel: the agent reports counts, timings, lag, checksums and at most 50 keys. Every run step and cutover action is audited.

M11.1 — More write-plane engines

• Snowflake and BigQuery as migration targets: Snowflake loads through agent-local files, PUT and COPY INTO; BigQuery through load jobs into a keel_stage dataset. Both are resumable per chunk, with scope-checked write credentials (grants and dataset IAM).
• Oracle as a migration source, with change data capture through Oracle's built-in LogMiner. No third-party library is needed; the database needs ARCHIVELOG and supplemental logging, which Keel checks and explains.

M12 — Commercial readiness (F20–F25)

• Plans and billing: Trial, Team, Business and Enterprise plans sit behind one entitlements service that every module reads.
  • Stripe subscriptions, checkout and the customer portal run over Stripe's REST API.
  • Webhooks are verified and applied once, in order.
  • Usage meters warn Owners at 80% and 100%.
  • A downgrade below current usage is blocked, with a list of what to remove first.
  • An expired trial becomes read-only, and its data is kept for 30 days.
• Self-serve sign-up and onboarding:
  • /signin finds a company's identity provider from its verified email domain.
  • Sign-up creates an email-verified account. The /welcome wizard goes from a new workspace to a scanned sample model in well under three minutes, and resumes where the user stopped.
  • A getting-started checklist appears on Home, and every list screen has a designed empty state.
  • In sales-led deployments, only platform operators can create tenants.
• Agent fleet:
  • Agent pools and capabilities.
  • Automatic certificate rotation that doesn't drop running work.
  • Revocation within seconds, with the agent's work re-queued.
  • A version-skew policy that refuses agents two major versions behind and shows the update command.
  • Azure Key Vault, AWS Secrets Manager and HashiCorp Vault support.
  • A Helm chart and a Windows service installer.
• Operations:
  • Tenant offboarding, proven to leave zero rows.
  • Read-only support sessions that need the customer's consent and appear in the customer's audit log.
  • An operator console at /ops and a public /status endpoint.
  • Runbooks for incidents, restores, disaster recovery, offboarding and support sessions.
• Docs and in-app help:
  • A page per connector, each with a tested read-only role script.
  • An MCP tool reference and a glossary.
  • A "?" help panel with at least two articles for every screen.
• Product analytics:
  • Events carry route ids and error codes, never names from a customer's schema.
  • Tenant and user ids are hashed.
  • The sink is off by default; PostHog is optional, and EU tenants are routed to its EU host.
  • Owners can opt out.
• Screens rebuilt to the approved prototypes:
  • change requests and releases;
  • API, MCP & exports (/serving, /serving/exports);
  • Inbox (/inbox);
  • drift detection;
  • code maps.

M12.1 — Design gaps

• Find anything with ⌘K: metrics, tables, glossary terms, pages and actions. Type > to show only commands; if nothing matches, ask the assistant.
• Every screen handles every state:
  • loading skeletons;
  • in-app 403, 404 and 500 pages, with the trace id and Contact support;
  • a reconnecting banner when the API is unreachable;
  • a maintenance banner;
  • empty states with a "learn" link.
• Editors:
  • Metrics: the metric type drives the form, with live preview, compiled SQL and checks. Changes go through a branch and a change request.
  • Policies: masks and row filters, the blast radius, and a simulator that runs on synthetic rows.
  • Quality rules: six types, with a 30-day backtest and a dry run.
  • Smarter New term and Invite dialogs.
• SSO & SCIM:
  • Each tenant can connect its own OIDC or SAML identity provider.
  • Verified domains route sign-in to that provider, and SSO can be required, with a break-glass Owner.
  • SCIM 2.0 provisions people and maps groups to roles.
• Your profile (/me): your theme, time zone and number format, and your active sessions with sign-out.
• Help and support:
  • The help panel has docs search, shortcuts and what's new.
  • Contact support attaches only the screen, the trace id and the app version.
• Migrations: a migrations list with stage progress, and a 3-step New migration sheet.
• Emails: every email shares one design. New: trial-ending notices, payment receipts and a deletion certificate after offboarding. Slack and Teams alert cards carry one action.
• Docs and status:
  • A redesigned docs site.
  • A self-hosted status page with 90-day uptime, incidents written by operators, and email subscriptions.

M12.2 — Engineering gaps

• Plans are enforced:
  • Governance, SSO and the private agent follow the tenant's plan; a screen outside the plan says "Not in your plan".
  • A downgrade never weakens what is in force: policies, your identity provider and enrolled agents keep working, frozen until an upgrade.
  • Audit retention follows the plan.
  • A read-only tenant's scheduled jobs pause.
• SCIM:
  • Deactivating someone in your identity provider signs them out at once.
  • SCIM attributes (department, cost centre and others you map) feed row-filter policies.
• Your preferences everywhere: your time zone and number format apply on every screen. The top bar names the Settings tab you're on.
• Every screen handles every state:
  • The remaining screens have skeletons and error states.
  • Below 1024px the navigation becomes a drawer.
• Editors:
  • Metrics can limit the dimensions they may be sliced by.
  • The rule editor shows the table's load cadence and the metrics that depend on it.
• Agent self-update:
  • Agents update themselves from signed releases on a stable, beta or pinned channel.
  • A failed update rolls back automatically.
  • An update never interrupts a migration run.
• Migrate: choose which tables a migration covers.
• Receipts: receipts in zero- and three-decimal currencies show the right amounts.

M12.3 — Launch engineering

• Plans are enforced when you add things:
  • Seats, source connections and workspaces stop at the plan's limit, with a "Choose a plan" prompt for Owners.
  • The plan shown in the ops console and analytics now follows billing.
  • Operators set contracts, with per-customer limit overrides, from the command line.
• Deleting an organization has a 7-day grace period:
  • Owners request it in Settings › Security, and everyone sees the date.
  • The organization is read-only meanwhile, and Owners or operators can cancel before the date.
• Removing access always works: SCIM deactivation, removing members and revoking keys, agents and support access work even while an organization is read-only.
• SCIM mapping changes apply at once, from the last values your identity provider pushed.
• Paused one-off jobs run when a read-only organization becomes active again.
• Support sessions are never unaudited: no audit record, no access.
• Agent releases:
  • An offline root key certifies the signing key, so it can rotate without re-enrolling agents.
  • Agents install only packages listed in a signed release manifest.
  • Self-update is proven under systemd.
• Production deployment:
  • Container images for every host.
  • Azure infrastructure as code: Container Apps behind Front Door with WAF, PostgreSQL with zone-redundant HA and geo-redundant backup, Managed Redis and Key Vault.
  • A sovereign single-tenant deployment into a customer's own Azure subscription.

M12.4 — Platform owner

• A platform console for Anchor:
  • It opens on an overview of customers, trials, contracts, usage and estimated revenue, plus the demo-request leads.
  • Anchor's own tenants are kept out of the figures.
• Provision customers without becoming one:
  • Create a customer's tenant and invite their administrator as Owner; Anchor never joins it.
  • Set their contract, extend their trial, or mark a tenant internal, all from the tenant's page.
• The founder is the platform owner: only the owner invites or removes operators, requires their sign-in method or hands over ownership.
• Customer data stays private: no one at Anchor, the owner included, sees inside a customer's tenant without the customer's approval.

Known limitations

Area	Limitation
Identity	Per-tenant SAML is registered with Keycloak but not yet proven with a real SAML identity provider's login. Data-residency routing is not built.
Connectors	Azure SQL Entra managed identity is not implemented. No query-log harvesting for any kind (the query-log join signal is always 0). Cloud warehouses are tested with emulators and fakes; live checks run only with account secrets and are not wired into CI. Redshift and BigQuery sampling is not repeatable.
Inference	TPC-DS is not in the benchmark set; the LLM-mode benchmark and semantic (vector) search need an embedding / model key in CI. The per-tenant LLM token budget is counted per worker process. openai / azure-openai tenant providers run heuristics-only.
Workspace	Conflict resolution restarts if the branch moves again during resolution. The React Flow attribution stays visible pending a licence decision.
Data quality	dbt tests / Great Expectations import has no preview; dbt where filters are not applied (noted in the evidence) and GE aggregate expectations (mean, min, max) are reported, not imported. Rule-result filters apply to the loaded pages only (no server-side filters).
Governance	The /governance dashboard has no approved prototype yet (it reuses Home and Quality patterns).
Serving	API keys are evaluated as Analysts with no attributes. No RateLimit-* headers on successful responses. One source per query (no federation). Conversion metrics are not compiled (422).
Assistant	The ≥ 90% accuracy target is not measured yet (needs an LLM key as a CI secret). No charts or streaming; LLM token usage is not persisted (Settings › Usage says so).
Exports	Only GitHub pushes (GitLab / Azure Repos answer 422). Catalog push (DataHub, OpenMetadata) is v1.1. Power BI TMDL is checked structurally in CI and manually in Tabular Editor / Power BI Desktop before release.
Imports	Files or a zip only (no import from a Git repository reference yet). The change request diff lists every imported object as added (the import branch starts at the model's empty root so conflicts keep both versions); the breaking-change check does not see a conflict resolved toward the import. LookML extends / refinements and Cube extends are reported, not resolved.
Lineage	Heuristic SQL parsing: recursive CTEs, table functions, PIVOT and dynamic SQL are reported, not guessed; dbt manifests give dataset-level lineage; backtick / Snowflake view text is not parsed.
Accessibility	Automated axe (WCAG 2.2 AA) and keyboard checks cover every route in both themes; no screen-reader pass yet (docs/accessibility-audit-m9.md). The narrow-screen navigation drawer awaits product-owner sign-off.
Audit	External WORM anchoring of the chain is a follow-up (verification is incremental nightly plus a full weekly recompute).
SQL interface	Beta behind a flag: one table per SELECT (no joins, subqueries or HAVING), cleartext password over TLS only (no SCRAM), no direct TLS negotiation, COPY and the function-call protocol refused; psql \d meta-commands fail (OPERATOR(pg_catalog.~) is not parsed; browse information_schema); BI-tool coverage beyond Npgsql and JDBC-style metadata queries is best effort.
Private agent	Query-log reading has no agent path. A credential that is a connection option besides the secret (e.g. an encrypted key's passphrase) cannot come from the agent's store. Server jobs wait in place for agent answers (a worker slot per waiting call). Self-update covers Windows service and Linux binary installs. The Linux path is proven under a real systemd; the Windows helper is tested with fakes only. Containers are updated by whoever deploys them. Rotating the release-signing key needs no re-enrolment, but losing the offline release root does. The release workflow publishes only once Anchor enables it and configures Key Vault signing. Azure Key Vault and AWS Secrets Manager are verified on recorded HTTP only.
Billing (M12)	Payments are invoiced by Anchor; self-serve checkout waits for Anchor Pay (Stripe Tax, ACH/SEPA and the portal are untested). Contract end dates are informational (no expiry or reminder), and contracts are set from the CLI only.
Sign-up (M12)	The sign-in magic link needs a Keycloak extension. The US/EU region is recorded but data is not routed by region.
Operations (M12)	The Azure infrastructure (Bicep, ADR-0025) is validated offline but not yet deployed: it needs Anchor's subscription, domain and secrets, and its first deployment should be to staging. The Key Vault firewall and Redis public access defaults need tightening before production. The public status page is a third-party provider (the built-in page serves in-app notices), Contact support goes to an email address (no helpdesk integration), and offboarding has a 7-day grace period.
Migrate (M10)	Mapping confidence is conservative (correct matches often score 0.68–0.89). Code maps are inferred only when the target carries value sets (uploaded DDL/dbt, not harvested CHECK constraints). Code generation and reconciliation run against real engines for PostgreSQL (and SQL Server as a source); the other dialects are golden-tested. No plan-diff view yet. Keel doesn't execute migrations (F19).
Migrate run (M11)	Write-plane targets: PostgreSQL, SQL Server, Snowflake and BigQuery (M11.1; the cloud targets are verified on unit tests and the BigQuery emulator, not yet on live accounts). Sources: PostgreSQL, SQL Server and Oracle (LogMiner CDC, ADR-0022). One source per run. No run history view or "abandon run" action yet. The 10M-row kill-and-resume load and the 10-minute CDC soaks (PostgreSQL, SQL Server CDC and change tracking, Oracle) pass nightly; SQL Server CDC needs max text repl size = -1 for large-value columns.
Packaging	Images for the API, worker, scheduler, MCP, SQL gateway, web and Keycloak, plus the agent (image, Helm chart, Windows and Linux packages), are built in CI and published on release tags. The SQL gateway image is not deployed by the Bicep (it needs TCP ingress). The Oracle driver licence must ship with self-hosted packages.

Upgrade notes

• Production: first release — run dotnet Keel.Api.dll migrate as a pre-deploy job; migrations are append-only from here.
• Development databases created before M1: recreate them (docker volume rm keel-postgres-data); the Identity and Audit initial migrations were regenerated.
• Development databases with pre-M6 audit rows: audit snapshots are now stored as text, so older rows verify as Modified. Reset the database (same command) to get a clean chain.
• Other development databases (M2–M8): migrate in place. Existing models get lineage on their next release or scan (or Rebuild lineage); the first scan after upgrading from M2 proposes everything.
• Local Keycloak: the dev realm gained a keel-seed client for the demo seeder; it is imported when the Keycloak container starts, so restart the AppHost.
• M12:
  • Tenants created before M12 become Enterprise contracts with their current modules.
  • The dev realm gained the keel-identity-admin client, the Google and Microsoft brokers (shown only when configured) and operator@keel.local. Restart the AppHost to import them.
  • Sales-led deployments should set Keel:Signup:AllowTenantCreation=true only where anyone may create a tenant.
• Runtime: .NET 10 LTS (also builds on .NET 11), PostgreSQL 17 with pgvector and pg_trgm, Redis, Node 22+ with pnpm 10 for the web app.