The data-intelligence layer of the Forge suite
Ask for geospatial data by intent and get back the best-fit correct dataset — ranked by coverage and resolution, with access cost as the deciding tiebreaker — across thirteen heterogeneous source types. ForgeGIS computes, ForgeMind reasons, ForgeGIS Studio renders; ForgeData decides which data to use and how to get it.
Three short answers for the technical evaluator.
ForgeData sits beneath the suite and owns the cross-cutting problem of data discovery and access. It keeps one catalog — what you can query and the recipes that refresh it — and routes every request to the best-fit dataset across local files and remote services alike, with no hardcoded paths and no per-project glue.
Most platforms make the customer build the routing layer themselves: bespoke catalog tables, hand-maintained config, hardcoded paths nobody wants to own. ForgeData ships that layer in the box, so the suite works against a realistic, scattered data landscape on day one rather than after an integration project.
The catalog is the configuration — the data-source recipes live in the same GeoPackage file as the inventory, so nothing drifts out of sync, and API keys stay in the environment, never the file. Routing is fidelity-first: coverage, then resolution, then extent-fit, with access cost as the deciding tiebreaker.
ForgeData's core differentiator. Name an operation and an area of interest, and find_optimal_for_operation returns a ranked, costed, deduplicated list of catalog entries that can serve it — with no hardcoded paths.
After the first read of a remote dataset, ForgeData stores the measured wall-clock latency and uses it instead of the static formula — the cost signal sharpens the longer the suite runs.
Thirteen source-type implementations cover the common public and private geospatial sources — all addressable through one uniform query interface. The customer's environment can be a mix; the caller sees one ranked answer.
The same correctness discipline the rest of the Forge suite is built on, applied to data.
All state — datasets and the recipes that refresh them — lives in one standard
GeoPackage. No companion sources.yml to drift out of sync, and no secrets baked
in: the catalog stores only the environment-variable name that holds a key. Safe to copy, ship
to a field laptop or air-gapped site, or commit — and readable in QGIS or DB Browser.
Every tool failure returns a structured envelope with a specific, machine-readable reason
— aoi_out_of_coverage, windowed_read_unsupported,
bbox_invalid — never an empty success or the nearest wrong tile. For
coverage gaps it even names the registered source whose sync could acquire the area.
DEMs flatten open water to a literal 0 m that reads as solid ground and corrupts slope, viewshed, and line-of-sight. ForgeData recodes over-water cells to NoData at one shared read seam — geometry-driven and source-agnostic across SRTM, Copernicus, 3DEP, Terrarium, and remote WCS — so every consumer inherits honest terrain. A strict no-op until a water layer is present.
When ForgeGIS computes a slope raster over an area, the result registers back into the catalog as a derived product, pinning its parent, operation, parameters, and content hash. The next request that needs the same thing finds it cheaply instead of recomputing — so over a long-running project, workflows get faster the longer the suite runs.
The routing work could in principle live inside ForgeGIS, ForgeMind, or Studio. It deliberately does not — each of those has a sharp job, and folding data-intelligence concerns into any of them would blur that boundary. ForgeData is the home for the cross-cutting problem, so it can evolve independently of every consumer.
ForgeMind and Studio talk to ForgeData over MCP — the same stdio JSON-RPC surface any third-party MCP client could use. ForgeGIS is consumed by ForgeData as an in-process Java library for the actual data reads, so windowed-raster extraction and elevation queries happen with no network hop. Underlying sources stay exactly where they are.
One layer, three readers. Each one-pager leads with the parts of ForgeData that matter most to that audience.
Its entire state is a single local file with no embedded secrets, so a curated catalog ships to a field laptop or air-gapped site and queries on arrival. Fail-closed on coverage, auditable provenance on every dataset, honest terrain at the line-of-sight seam.
Download defense & IC one-pager (PDF)A 49-tool server an agent hands a data question to — which dataset covers this area at the right resolution, and what does it cost to read? — and gets back a ranked, costed answer instead of a hardcoded path, with structured errors an agent can branch on.
Download agent-builder one-pager (PDF)When a ForgeMind workflow asks for a viewshed or a slope analysis, the agent does not need to know one dataset is a local SRTM tile and another a remote COG on S3. It calls one operation and gets back a ranked, costed list — best-fit correct dataset first.
Download general sales one-pager (PDF)All ForgeData collateral. Direct download — no email gate, no form wall.
The catalog model, cost-aware routing, the operation registry, the source types, the MCP tool surface, the read paths, and deployment guidance. The substantive document for technical evaluators and platform engineers.
Download PDFFront/back overview. General-purpose first-touch document covering positioning, headline numbers, and the routing story at a glance.
Download PDFFor defense and intelligence programs and prime integrators. Leads on the secret-free portable catalog, fail-closed coverage, and disconnected deployment.
Download PDFFor AI agent builders and MCP-native runners. Leads on the 49-tool MCP surface, intent-based routing, structured refusal, and derived-product memory.
Download PDFEvaluation access, suite licensing, and partnership inquiries — we read every email. An evaluation build is available to qualified teams on request.
rich@seaglassfoundry.com