mapsmith 0.2.0__tar.gz → 0.2.2__tar.gz

mapsmith-0.2.2/.dockerignore

@@ -0,0 +1,35 @@
+# The build only needs pyproject/README/LICENSE/src, but everything else in the
+# directory is still sent to the daemon without this file — including a local
+# .venv, built wheels and any .env sitting next to them. CI builds from a clean
+# checkout, so nothing private has ever reached a published layer; this is here
+# so a `docker build .` on a working machine cannot be the first time.
+.git/
+.github/
+.venv/
+venv/
+env/
+dist/
+build/
+*.egg-info/
+__pycache__/
+*.py[cod]
+.pytest_cache/
+.ruff_cache/
+.mypy_cache/
+.ipynb_checkpoints/
+
+# secrets and local configuration
+.env
+.env.*
+*.pem
+*.key
+
+# large or irrelevant to the image
+benchmarks/
+docs/
+examples/
+tests/
+deploy/
+*.md
+!README.md
+uv.lock

{mapsmith-0.2.0 → mapsmith-0.2.2}/.gitignore

@@ -22,6 +22,12 @@ venv/
 *.provenance.json
 data/
 
+# Scratch databases: probing the DuckDB sandbox (ATTACH, COPY) drops these in
+# the repo root, and one of them reached a public commit before we noticed.
+*.db
+*.duckdb
+*.wal
+
 # OS / editors
 .DS_Store
 Thumbs.db

mapsmith-0.2.2/CHANGELOG.md

@@ -0,0 +1,336 @@
+# Changelog
+
+All notable changes to MapSmith are documented here, in the format of
+[Keep a Changelog](https://keepachangelog.com/en/1.1.0/). This project follows
+[semantic versioning](https://semver.org/).
+
+## [Unreleased]
+
+## [0.2.2] — 2026-08-22
+
+A security release. The fixes below close holes present in 0.2.1, which is
+published: **if you run MapSmith on data or paths an agent can influence,
+upgrade.** The headline is that a plain local file could make GDAL fetch a URL
+or read a dataset from outside the workspace, and that credentials could reach
+a manifest.
+
+Worth saying plainly, because it shaped the release: each fix here was found by
+auditing the previous one. The remote opt-in left `.vrt` able to reach the
+network; closing `.vrt` left `GDALG` and `MRF` doing the same thing; refusing
+credential SQL wrote the credential into the refusal message. The pattern is
+not bad luck — it is what happens when a guard is written against an instance
+instead of a class, and the response in each case was to move the check one
+level down rather than add another name to a list.
+
+### Added
+
+- **`funding.json`** at the repository root ([FLOSS/fund
+  manifest](https://fundingjson.org/)), stating what the project would use
+  funding for: the correctness suite and the provenance specification. No
+  payment provider is published — arrangements are made in writing.
+
+### Changed
+
+- **Remote and virtual paths are refused by default** (`MAPSMITH_ALLOW_REMOTE=1`
+  to allow them). GDAL `/vsi*` and `https://` forms used to be accepted whenever
+  no workspace was set, justified as being the user's own responsibility — and
+  the user is not who decides: the path is written by the model, from whatever it
+  read, so a third-party dataset carrying "the updated layer lives at
+  https://evil.tld/x.gpkg" was enough to have GDAL parse attacker-chosen bytes
+  in-process. The refusal now covers both path arguments and `run_sql` text,
+  which closes the SSRF that came with it (raw SQL could read any endpoint the
+  host can reach — internal services, cloud metadata — and return the content in
+  the tool result) as well as the `INSTALL ... FROM '<url>'` fetch. Cloud-native
+  data stays a supported use case: the capability is gated, not removed. A
+  workspace refuses remote forms regardless, and validated plans stay strict
+  whatever the setting.
+- **The container is unprivileged and confined by default.** The published image
+  runs as uid 1000 instead of root and sets `MAPSMITH_WORKSPACE=/data` itself, so
+  `docker run -v your/data:/data ghcr.io/mapsmith-ai/mapsmith` gets the path jail
+  and the sandboxed SQL engine without the operator having to remember `-e` — the
+  wrong way round for a default. Two consequences before you upgrade: a bind
+  mount owned by another user is no longer writable (pass
+  `--user $(id -u):$(id -g)`), and everything outside `/data` is refused,
+  including remote paths, which a workspace refuses whatever
+  `MAPSMITH_ALLOW_REMOTE` says. The Kubernetes example states the same posture at
+  pod level (`runAsNonRoot`, `readOnlyRootFilesystem`, dropped capabilities).
+
+### Fixed
+
+- **GDAL indirection was closed as an instance, not as a class.** Deregistering
+  the drivers behind `.vrt` left `GDALG` and `MRF` doing the same job. GDALG
+  (*GDAL Streamed Algorithm*, GDAL 3.11) reads a JSON document holding a `gdal`
+  command line and runs it when the dataset is opened, and it is recognised by
+  **content, not by extension** — so the filename tells you nothing, and the
+  command line can name a local path as readily as a URL. Measured with remote
+  reads off **and** a workspace set: a file called `roads.geojson` inside the
+  workspace issued a GET, and another read a dataset from *outside* the
+  workspace and handed back its rows. That is containment broken, not only
+  egress. MRF is narrower — extension-gated, fetched on the first pixel read.
+  Both are now skipped, along with the remaining drivers GDAL's own security
+  page names as opening other datasets internally.
+
+  The list is not the fix. It was correct when written and became incomplete
+  because GDAL shipped a new driver, which will happen again. A test now
+  enumerates the drivers registered in a clean subprocess and fails on any name
+  nobody has reviewed — the only version of this check that keeps working
+  across upstream releases.
+- **A workspace no longer loses to the opt-in.** `MAPSMITH_ALLOW_REMOTE=1`
+  together with `MAPSMITH_WORKSPACE` re-registered the indirection drivers,
+  because the predicate answering "is remote allowed" read only the environment
+  variable while its own documentation said a workspace overrides it. Two
+  callers compensated for that and one did not. The predicate answers the whole
+  question now: a check each caller has to remember to add is a check that will
+  be missing somewhere.
+- **Plan manifests are redacted, and the credential refusal no longer quotes the
+  credential.** `<output>.plan.json` is written as a plain dict, so the redaction
+  applied to every provenance record never reached it — while `goal`, each
+  step's `comment` and a failed step's `error` all carry text written by the
+  model or the user. The sharp case: refusing `ATTACH 'postgres://user:pw@…'`
+  produced a message quoting the fragment, password included, and that message
+  is what the manifest recorded. The mechanism that exists to keep credentials
+  out of manifests was putting one in. Redaction now runs on the whole manifest
+  at the point it becomes a file.
+- **A credential written with a quoted identifier is refused.**
+  `SET "s3_secret_access_key" = '…'` and `PRAGMA "…"='…'` defeated *both* layers:
+  the refusal pattern required the credential word to follow `SET` contiguously,
+  and the redaction pattern allowed only whitespace between the name and the
+  `=`, so the closing quote broke each of them. This was not one of the two
+  documented limits — the name was perfectly recognisable.
+- **`crs_decisions` and `notes` are redacted on the paths that actually run.**
+  Redaction happened at construction, and no engine passes those fields to the
+  constructor — every one assigns afterwards. So two of the four fields
+  SECURITY.md lists as covered were never redacted in practice, and
+  `parameters_redacted` stayed false. Redaction now also runs in `write_for`,
+  the single point where a manifest becomes a file, and covers `verification`
+  and `repairs` as well. The test that claimed to cover this passed both fields
+  as constructor arguments — a shape no caller uses — so it was green and
+  proved nothing; it now uses the real one.
+- **A local GDAL indirection file could reach the network from inside a
+  workspace.** A `.vrt` is a plain local path, so the path guard, the SQL scan
+  and DuckDB's `allowed_directories` all saw a local file while GDAL fetched
+  whatever its `<SrcDataSource>` named — measured on 0.2.1 as HEAD and GET
+  leaving the process with `MAPSMITH_ALLOW_REMOTE` unset **and**
+  `MAPSMITH_WORKSPACE` set, through the GeoPandas/pyogrio path. That
+  contradicted the one promise SECURITY.md states as testable, so the fix is at
+  GDAL's level: with remote reads off, the indirection and network drivers are
+  deregistered before the geospatial stack initialises. The opt-in restores
+  them, including when a parent process installed the policy — containers pass
+  their whole environment down, and a switch that cannot lift an inherited
+  policy is a switch that does nothing. Found by an adversarial audit of the
+  commit that introduced the opt-in, i.e. of the fix itself.
+- **Credentials no longer reach provenance manifests or the job ledger.**
+  `run_sql` records the query, and manifests are made to be shared, so an agent
+  emitting `CREATE SECRET (... SECRET 'AKIA…')` in the same session used to write
+  that key into a file destined for a bug report. **SQL that configures a
+  credential is now refused before it runs** — `CREATE SECRET` in any spelling,
+  `SET`/`PRAGMA` of a credential-bearing setting, `ATTACH` carrying a password or
+  URI userinfo — with a message pointing at where credentials belong: the
+  environment of the process that starts the server, out of reach of a tool call.
+  Nothing documented used that path, and in MapSmith's sandbox only one secret
+  type was even constructible.
+
+  Redaction stays as the second layer for credentials that reach a manifest
+  without being SQL (a signed URL as an input path, a connection string as an
+  argument), now covering `crs_decisions`, `notes`, input paths and the ledger's
+  `error` column — an engine error quotes the statement that failed. Masked
+  values are quoted, so a redacted statement still parses when pasted back into
+  a client.
+
+  Refusal came first because redaction alone did not hold: an adversarial audit
+  of the shipped version escaped it with `MAP{'Authorization': 'Bearer …'}`, an
+  `E'…'` literal, dollar quoting and a comment between name and value — and the
+  `E'…'` case masked the *wrong* argument while keeping the secret, producing a
+  manifest both misleading and leaky. All four are regression tests now.
+  Remaining limits, documented rather than implied: detection is name-based, so
+  a bare positional secret is not caught, and neither is a URI that
+  percent-encodes the colon of its own userinfo.
+- **GeoParquet 2.0 files are read instead of refused.** 2.0 (`v2.0.0-rc.1`)
+  moves geometry into Parquet's own `GEOMETRY`/`GEOGRAPHY` logical types and
+  makes the `geo` metadata key optional, and DuckDB already writes such files.
+  MapSmith read them inconsistently: `run_sql` worked, `describe_dataset` failed
+  with a raw GeoPandas `Missing geo metadata` error, and the CRS probe reported
+  `unknown` **even for a file that states its CRS** — which made the CRS
+  precondition refuse valid work for a wrong reason. The CRS now comes from the
+  logical type when there is no `geo` key, in all the forms met in practice: the
+  spec default (`OGC:CRS84`), an authority string, `projjson:<key>`, and the
+  whole PROJJSON document inline, which is what DuckDB writes.
+
+  One form is deliberately not resolved: `srid:<n>`. The spec defines it as a
+  numeric identifier and names no authority (its own example is `srid:0`), so
+  reading it as `EPSG:<n>` would be MapSmith inventing a coordinate system and
+  recording it as fact. Such a file is treated as having no CRS, so the CRS
+  precondition refuses it like any other input without one. The message does
+  not yet quote the `srid:` declaration that caused it, which would tell the
+  agent what to fix — tracked separately rather than claimed here.
+
+  **Writing now states its flavour instead of inheriting one.** `run_sql`
+  materialises with `geoparquet_version 'BOTH'`, so one output file carries
+  Parquet's native geometry types (CRS included as PROJJSON) *and* the 1.x `geo`
+  metadata — a 2.0-native reader and GeoPandas 1.x both open it, which is
+  asserted by a test that reads it back both ways. This was not a free choice:
+  DuckDB 1.4 wrote the native types by default and 1.5 changed the default back
+  to 1.x, so the installed engine version was silently deciding the canonical
+  output format of a provenance product. The GeoPandas writer path stays 1.x,
+  because GeoPandas 1.1 caps `schema_version` there.
+- **Dependency floors raised for a correctness reason, not a housekeeping one.**
+  `pyarrow>=21`: measured on a file DuckDB itself produced, pyarrow 18 and 19
+  **raise** on Parquet's geospatial logical types ("Thrift LogicalType that is
+  not recognized"), 20 opens the file but reports the type as `Undefined`, and 21
+  reports `Geometry` with its CRS. Below 21, MapSmith could not read back its own
+  `run_sql` output — the CRS probe returned `unknown`, which made the CRS
+  precondition refuse a file MapSmith had just written. `duckdb>=1.5` is the
+  floor for the `geoparquet_version` option above.
+- **Persistent DuckDB secrets can no longer be created from a tool call.** They
+  are written to `~/.duckdb/stored_secrets` — outside any workspace and beyond
+  the session. A workspace already refused that write; the connection now sets
+  `allow_persistent_secrets = false` in both modes, before locking the
+  configuration.
+- **The `mcp` floor is 1.28.1.** The SDK range MapSmith allowed admitted three
+  High-severity advisories (CVE-2026-59950, CVE-2026-52869, CVE-2026-52870).
+  None is exploitable here — MapSmith uses stdio and stateless Streamable HTTP
+  with no authentication, never the websocket transport, never task handlers —
+  but a fresh install could resolve to a version carrying them, and a scanner
+  cannot know the difference.
+- **`duckdb` is now capped below 2.0.** The floor was raised to 1.5 for a
+  correctness reason (above); the cap is for a different one. DuckDB 2.0 is on
+  the autumn-2026 calendar with breaking changes, and an unbounded requirement
+  means the first install after that release can fail with nothing on our side
+  having changed. A pin you have to lift deliberately beats an install that
+  breaks on someone else's schedule.
+
+## [0.2.1] — 2026-08-20
+
+Three fixes you would rather not find yourself. All came from reviewing 0.2.0
+*after* it shipped, and all were reproduced through the real MCP tools instead
+of read off a diff.
+
+### Fixed
+
+- **An empty spatial join no longer crashes before writing its manifest.**
+  DuckDB writes no GeoParquet `geo` metadata for a zero-row result, so reading
+  the output back raised — on the default engine path, for exactly the case the
+  verification checks exist to explain, while the tool description promised a
+  warning. A zero-row result is now written as a valid empty GeoParquet with the
+  analysis CRS and the joined schema, and the join goes through the same audited
+  writer as everything else, so the manifest exists even when a check fails.
+- **A GeoParquet declaring `crs: null` is no longer read as CRS84.** MapSmith
+  invented a coordinate system and recorded it in the manifest as fact, with
+  `verified: true` — the worst class of bug a provenance tool can have. The
+  GeoParquet spec distinguishes an *absent* `crs` field, which does mean CRS84,
+  from an explicit null, which means unknown; so does MapSmith now, and an
+  unknown CRS is refused by the preconditions like any other missing CRS.
+- **The DuckDB sandbox locks its configuration in every mode.** The lock used to
+  apply only under `MAPSMITH_WORKSPACE`, so a multi-statement call could switch
+  extension autoloading back on, and an explicit `LOAD httpfs` was never blocked
+  at all. Locking is now unconditional and DuckDB's HTTP and S3 filesystems are
+  disabled, while local reads keep working.
+- **The security documentation no longer claims that unconfined mode blocks
+  network egress.** It does not, and it never did: GDAL carries its own HTTP
+  client, so `ST_Read('/vsicurl/https://…')` in raw SQL reads whatever the host
+  can reach — internal services and metadata endpoints included — and the URL it
+  names can carry data out. Remote reads are deliberately available while the
+  server is unconfined, because cloud-native data is a feature; the claim that
+  the network was closed anyway was the bug. README and SECURITY.md now state
+  the price of that choice, and two tests pin both halves of it: without a
+  workspace the read succeeds, and with one it is refused *before any request
+  leaves*, asserted by counting requests at a loopback server instead of
+  matching an error message. If you do not trust your `run_sql` input, set a
+  workspace.
+- **The multi-layer guard fails closed.** A container whose layer list could not
+  be read looked like a single-layer file, and mechanical geometry repair would
+  then have destroyed the other layers while recording success.
+- **`execute_plan` reports `repairs` per step.** Geometry MapSmith rewrote was
+  visible in a single-operation result and invisible at plan level.
+- **Manifests record `EPSG:32632`, not 2.5 KB of PROJJSON**, when a GeoParquet
+  input carries its CRS as an embedded projection object.
+- **The example `docker-compose.yml` binds MinIO to loopback.** It published
+  ports 9000/9001 on every interface with the documented development
+  credentials.
+
+### Changed
+
+- **The provenance badge has three states instead of two.** "All critical checks
+  passed" is vacuously true when no critical check ran — a `run_sql` manifest,
+  for one — so an output whose only check had *failed* rendered with the same
+  green tick as a verified buffer. `provenance_summary` now reports `verified`,
+  `failed` or `unchecked`, with the reason, and the map panel renders all three.
+  The `verified` boolean stays in the payload, computed correctly, so a client
+  reading it gets a fix rather than a breaking change.
+- **The README says when *not* to use MapSmith**, and the
+  [benchmark results](docs/benchmarks.md) are linked from it — they were public
+  for a day with nothing pointing at them.
+
+## [0.2.0] — 2026-08-20
+
+The first release you can point an agent at and trust the answer: results are
+verified on the way in and on the way out, plans are checked before anything
+runs, and the server can be confined to a single directory.
+
+### Added
+
+- **Interactive map inside the chat.** `preview_map` renders your layers on a
+  pan/zoom map panel in any client implementing the
+  [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview)
+  extension (field-tested on Claude Desktop), with an OpenStreetMap backdrop
+  and a provenance card per layer showing operation, engine and one of three
+  states: `verified ✓`, `verification failed`, or `not verifiable` when no
+  critical check ran. Fully self-contained; on clients without MCP Apps the
+  same call returns structured data.
+- **Typed plans.** `validate_plan` statically checks a multi-step analysis —
+  operations exist and are installed, arguments complete and well-typed,
+  `$step` references resolve backwards, input files exist, outputs don't
+  collide, and the CRS of every intermediate is simulated from the real
+  inputs — and returns machine-actionable error codes. `execute_plan` then
+  runs the validated plan with per-step provenance plus a plan-level manifest
+  fingerprinting the exact plan that produced the result.
+- **Terrain and hydrology** on the Whitebox Workflows engine (`[whitebox]`
+  extra): `hillshade`, `flow_accumulation` (D8, with depression filling) and
+  `watershed` (many pour points at once).
+- **Zonal statistics** with exact fractional pixel coverage via exactextract
+  (`[raster]` extra).
+- **A searchable operation catalog.** `list_operations` ranks capabilities by
+  relevance (BM25) so an agent can discover what exists — including what is
+  planned but not yet available — instead of guessing from a wall of tools.
+- **Workspace confinement.** Set `MAPSMITH_WORKSPACE` and every path argument
+  must resolve inside it, `run_sql`'s DuckDB connection is sandboxed to that
+  directory with extension loading refused and memory/temp-disk capped, and
+  UNC hosts and NTFS alternate data streams are refused in every mode.
+- **Verification on the way in.** Operations check their inputs for the
+  failures that produce plausible junk: a missing CRS is refused outright, and
+  empty inputs or extents that cannot possibly intersect come back as named
+  warnings with hints — in the tool result, not only in the manifest.
+- **Bounded deterministic repair.** Mechanically broken output geometry is
+  repaired (`make_valid`, at most two rounds, written atomically) and every
+  attempt is recorded in the manifest: a repaired output never looks like one
+  that was right the first time.
+- **A notebook gallery** (`examples/`) and a
+  [benchmarks page](docs/benchmarks.md) with the harness that produced it.
+
+### Fixed
+
+- **Wrong terrain results from ordinary compressed rasters.** Whitebox
+  Workflows 2.x does not undo the TIFF predictor when reading, so any DEM
+  saved with `PREDICTOR=2` or `3` — the standard encoding for elevation data —
+  produced hillshades and flow accumulations that looked like terrain and were
+  not. MapSmith now detects the predictor and converts the input first,
+  recording it in the manifest.
+  ([upstream report](https://github.com/jblindsay/whitebox_next_gen/issues/32))
+- **GeoParquet outputs from the vector engines** were written through a GDAL
+  path that produced unreadable files.
+- `run_sql` materialisations and the DuckDB/SedonaDB join fast paths now run
+  the same deterministic verification as every other writer, and record their
+  CRS decisions.
+
+### Changed
+
+- `spatial_join` with `engine="auto"` falls back to GeoPandas when the inputs'
+  CRS differ or are unknown, instead of joining mismatched coordinates.
+- The planning-failure figure quoted in the docs is stated as the upper bound
+  it is ("up to ~47%"), since the underlying study counts errors multi-label.
+
+## [0.1.0] — 2026-08-18
+
+First public release: the engine dispatcher (SedonaDB / DuckDB / GeoPandas),
+`run_sql`, the job ledger, stateless Streamable HTTP transport, and provenance
+manifests with deterministic verification on every writer.

{mapsmith-0.2.0 → mapsmith-0.2.2}/CLAUDE.md

@@ -19,6 +19,10 @@ MapSmith gives AI agents professional-grade geoprocessing via MCP, with **verifi
 - Version pins are deliberate: `mcp>=1.26,<2` (1.26 is the floor for resource `meta`, needed by the MCP Apps map panel; v2 renamed FastMCP→MCPServer; migration planned with MCP Tasks), `ruff>=0.16,<0.17` (new ruff minors add default rules and break CI).
 - Tests use closed-form expected values (e.g., a known 5×5 raster block → mean=22, sum=550) plus rejection-path tests; `pytest.importorskip` for extras.
 - Run `python -m ruff check .` before committing; CI runs lint + tests on Python 3.10/3.12 + Docker build.
+- **The floor is Python 3.10**, and local runs happen on a newer interpreter, so stdlib added
+  after 3.10 breaks only in CI: no `tomllib`, `datetime.UTC`, `StrEnum`, `contextlib.chdir`,
+  `ExceptionGroup` (3.11), no `itertools.batched`, `typing.override` (3.12). Ruff's
+  `target-version` catches too-new *syntax*; too-new *modules* are on you.
 - Docker (or `uvx` where wheels work) is the only supported install path — keep it true in docs.
 - Verify external-library APIs against primary documentation before coding against them; this repo has already been bitten by from-memory APIs three times.
 

{mapsmith-0.2.0 → mapsmith-0.2.2}/CONTRIBUTING.md

@@ -30,7 +30,7 @@ ruff check .
 
 ## Contributor License Agreement
 
-To keep dual-licensing possible (AGPL + commercial), we ask contributors to sign a lightweight CLA on their first PR (automated via bot). Your code always remains available under AGPL-3.0.
+To keep dual-licensing possible (AGPL + commercial), we ask contributors to sign a lightweight CLA on their first PR. There is no bot yet: if you open the first outside PR, we will agree the wording with you in the thread rather than block the merge on tooling that does not exist. Your code always remains available under AGPL-3.0.
 
 ## Code style
 

mapsmith-0.2.2/Dockerfile

@@ -0,0 +1,32 @@
+FROM python:3.12-slim
+
+# MCP Registry ownership proof: must equal the server.json "name" exactly.
+LABEL io.modelcontextprotocol.server.name="io.github.mapsmith-ai/mapsmith"
+
+# Geospatial wheels (pyogrio/shapely/pyproj) bundle their native libs; no system GDAL needed.
+WORKDIR /app
+COPY pyproject.toml README.md LICENSE ./
+COPY src ./src
+# raster + whitebox extras ship manylinux x86_64 wheels; the image is amd64-only.
+RUN pip install --no-cache-dir ".[raster,whitebox]"
+
+# Unprivileged by default (#19). uid 1000 on purpose rather than a high system
+# uid: the supported way to run this is a bind mount of your own data directory,
+# which on Linux is usually owned by the first human user — 1000. If yours is
+# not, pass `--user $(id -u):$(id -g)`.
+RUN useradd --create-home --uid 1000 --shell /usr/sbin/nologin mapsmith \
+    && mkdir -p /data \
+    && chown mapsmith:mapsmith /data
+
+# Workspace for datasets: mount your data here. Confined BY DEFAULT — the
+# supported path used to start unconfined unless the operator remembered `-e`,
+# which is the wrong way round for a default.
+VOLUME ["/data"]
+WORKDIR /data
+ENV MAPSMITH_WORKSPACE=/data \
+    HOME=/home/mapsmith \
+    MPLCONFIGDIR=/home/mapsmith/.config/matplotlib
+
+USER mapsmith
+
+ENTRYPOINT ["mapsmith"]

{mapsmith-0.2.0 → mapsmith-0.2.2}/MANIFESTO.md

@@ -12,7 +12,7 @@ name under. These are the commitments that follow from taking that seriously.
 ## 1. Engines compute. Models orchestrate.
 
 Every geometry and every number in a MapSmith result comes from executing a
-deterministic engine — GDAL, GeoPandas, DuckDB Spatial, WhiteboxTools,
+deterministic engine — GDAL, GeoPandas, DuckDB Spatial, Whitebox Workflows,
 SedonaDB. None
 of it is generated by a model, ever. The model's job is to decide *what* to
 run; it is never asked to produce a coordinate. This is the line that
@@ -38,8 +38,9 @@ that passed.
 
 ## 4. Coordinate systems are stated, never assumed.
 
-Silent CRS mismatch is the largest single cause of confidently wrong
-geospatial analysis. MapSmith refuses inputs without a CRS, never runs metric
+A silent CRS mismatch is the classic way a geospatial analysis comes out
+confidently wrong: the arithmetic succeeds, the map looks plausible, and the
+numbers mean nothing. MapSmith refuses inputs without a CRS, never runs metric
 operations on degrees without a declared reprojection, and writes the reason
 for every transformation into the manifest.
 
@@ -71,14 +72,15 @@ engine actually ran goes in the manifest.
 ## 7. Your data stays on your machine.
 
 No telemetry, no phoning home, no dataset uploads: MapSmith runs beside your
-data — on a laptop, in a container, on your own infrastructure. Two outbound
-requests exist and we would rather name them than have you find them: the
-in-chat map panel fetches OpenStreetMap background tiles (which reveals the
-map view you are looking at, and falls back to a plain background when the
-host blocks it), and the SQL engine downloads its spatial extension once per
-environment. Neither carries your datasets, and both are avoidable — skip the
-panel, pre-install the extension. The
-provenance manifests it produces belong to you, and they happen to be exactly
+data — on a laptop, in a container, on your own infrastructure. MapSmith itself
+makes two outbound requests, and we would rather name them than have you find
+them: the in-chat map panel fetches OpenStreetMap background tiles (which
+reveals the map view you are looking at, and falls back to a plain background
+when the host blocks it), and the SQL engine downloads its spatial extension
+once per environment. Neither carries your datasets, and both are avoidable —
+skip the panel, pre-install the extension. What an *agent* can reach through
+the SQL engine is a separate question, answered precisely in `SECURITY.md`.
+The provenance manifests MapSmith produces belong to you, and they happen to be exactly
 the kind of record an audit asks for: what ran, on what inputs, with what
 parameters, verified how. The EU AI Act's traceability obligations for
 high-risk systems are not a burden if your tooling produces that trail as a