{ "ok": true, "world": "geoai", "count": 115, "terms": [ { "slug": "acquire", "term": "Acquire", "aka": [ "Acquisition stage" ], "category": "loop", "short": "The online control-plane stage: DaC fetches imagery and labels, recording licenses, provenance, and content hashes for everything.", "definition": "Acquire is the stage where data actually comes in from the internet — the only stage, along with export, where the network is allowed at all. The Data as Code control plane (qukaizen-dac) fetches satellite or aerial imagery and OpenStreetMap labels, and records a license, a provenance trail, and a cryptographic content hash for every asset it takes in. That bookkeeping matters twice over: the hashes let every later stage prove it is using exactly the acquired bytes, and the license records enforce the discipline that open derived polygons never launder closed source imagery. Acquisition is a dac responsibility consumed here as pinned spec (dac ADR-0005, unmerged branch); qukaizen-geoai's own runtime never touches the network.", "example": "An operator points DaC at three OpenAerialMap scenes over northern Malawi. DaC downloads the GeoTIFFs, computes a sha-256 for each, records the CC-BY license and the STAC source URL, and pulls matching OSM building labels — so that months later anyone can verify which pixels, under which license, produced which predictions.", "related": [ "the-loop", "materialize", "control-plane", "imagery-licensing", "content-addressing" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md §1 (\"Data as Code is the control plane\") and \"Separate acquire, infer, and publish\"; docs/decisions/0001-repo-boundaries-and-pinned-contracts.md; read 2026-07-12" }, { "slug": "aerial-imagery", "term": "Aerial imagery", "aka": [ "Drone imagery", "UAV imagery", "Airborne imagery" ], "category": "imagery", "short": "Imagery captured from aircraft or drones: far sharper than satellite, but covering much smaller areas.", "definition": "Aerial imagery is photography taken from within the atmosphere — crewed aircraft or, increasingly, small drones — rather than from orbit. Flying low buys detail: drone imagery routinely resolves features a few centimeters across, sharp enough to distinguish a footpath from a drainage ditch or count individual tents in a camp. The trade-off is coverage and logistics: a drone maps a neighborhood per flight, not a country, and someone must be physically present to fly it. In humanitarian work, aerial imagery complements satellites — satellites give the broad, repeatable view; local drone flights fill in high-detail patches where mapping accuracy matters most, and communities can capture it themselves.", "example": "A flood-response team needs to know which footbridges in a riverside settlement survived. Satellite pixels at 10 meters blur a footbridge into the water. A local pilot flies a drone for twenty minutes and returns 3-centimeter imagery where every plank is visible.", "related": [ "satellite-imagery", "spatial-resolution", "ground-sample-distance", "humanitarian-mapping" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "ai-assisted-mapping", "term": "AI-Assisted Mapping", "aka": [ "Machine-Assisted Mapping" ], "category": "mission", "short": "AI proposes, humans dispose: model predictions serve as suggestions that speed mappers up, never as edits in their own right.", "definition": "AI-assisted mapping is the pattern where a model proposes and a human disposes: computer vision models detect likely buildings or roads in imagery and present them to mappers as suggestions, which the mapper accepts, corrects, or rejects. Done well, it changes the mapper's job from drawing every polygon to judging pre-drawn ones — much faster, especially across dense settlements. The ecosystem's working loop runs open imagery and OSM labels through fAIr for training and prediction, routes predictions to MapSwipe or editor plugins for human validation, and lands only reviewed results in OSM. The honest measure of success is not model accuracy alone but whether volunteers add more correct features per hour without degrading final map quality — a system-level question, not a leaderboard one.", "example": "Instead of tracing 300 buildings square by square, a mapper reviews a lattice of AI-proposed footprints over her task area. Most snap neatly onto roofs — accept, accept, accept. A few hallucinate sheds out of boulders, one misses a compound entirely. Twenty minutes of judgment replaces three hours of drawing.", "related": [ "fair", "human-in-the-loop", "mapswipe", "building-footprint", "mapper" ], "source": "github.com/hotosm/fAIr; qukaizen-geoai/docs/LANDSCAPE.md (executive summary, metrics that matter)" }, { "slug": "air-gap", "term": "Air gap", "aka": [ "Air-gapped system" ], "category": "runtime", "short": "The strongest isolation: no network path exists at all — zero-egress aims for the same guarantee on ordinary connected machines.", "definition": "An air gap is the strongest form of network isolation: the machine has no network path whatsoever — historically, literal air between it and any cable. Nothing can leak because there is physically nothing to leak through. Zero egress as designed here is related but distinct: the host machine may be an ordinary connected laptop, and isolation is imposed on one process tree by the sandbox — network namespace removed, syscalls denied, DNS disabled — for the duration of a run. The design's 'strict' enforcement level approximates a true air gap in software (the OS or VM proves no network interface exists in the run's world), while 'enforced' relies on syscall-level denial. The trade is deliberate: air-gap-grade guarantees during inference, without demanding volunteers own a dedicated offline machine.", "example": "A hospital's records system sits in a locked room with no network card — a true air gap. A mapper's MacBook has Wi-Fi on for email, yet the inference process running under the designed profile lives in a software world with no network at all: the same promise, scoped to one process, proven by the test suite.", "related": [ "zero-egress", "sandbox", "enforcement-level", "egress" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§3 enforcement levels, high-assurance microVM backend); qukaizen-geoai/docs/ROADMAP.md (M1 macOS backend)" }, { "slug": "arail", "term": "ARAIL", "aka": [ "Autoresearch AI Labs" ], "category": "stack", "short": "The shareable AI Lab for friends and family, with a local Buddy agent — the on-ramp where recruits explore Worlds like this one.", "definition": "ARAIL is QuKaiZen's on-ramp product: a learn-by-doing AI lab you clone and run on your own machine, built for friends, family, and the curious rather than for engineers. Three commands stand up a local web bench with a chat tab, a knowledge base, and an experiment loop, with a local Buddy agent as the resident guide; the lab is renameable in one line of config, because it is yours. ARAIL is BUILT and shared as a blueprint. In this mission's story it is where recruits land: the place to open a Knowledge World like this geoai one, quiz its docent, and get comfortable with locally run AI before touching the mapping pipeline itself.", "example": "A cousin clones ARAIL, runs setup and start, and opens 'PeanutLab' in a browser. Their first hour is spent wandering this very vocabulary — asking the docent what zero egress means — with no cloud account and nothing leaving their laptop.", "related": [ "knowledge-world", "docent", "qukaizen", "aerollm" ], "source": "arail/README.md (blueprint framing, quick start, tiers, Buddy); qukaizen-dac/data/worlds/README.md" }, { "slug": "basemap", "term": "Basemap", "category": "imagery", "short": "The reference layer under everything else — rendered map tiles or imagery you orient against.", "definition": "A basemap is the background reference layer of a map application — the familiar canvas of streets, terrain, or satellite imagery on which everything else is drawn. Technically it is usually a pyramid of pre-rendered map tiles, either cartographic (rendered from vector data such as OpenStreetMap) or imagery (mosaicked satellite or aerial scenes). Its job is orientation and context: predictions, task boundaries, and edits are overlays that only make sense against it. The choice of basemap carries consequences — an imagery basemap's date and license determine whether features traced against it may legally enter OSM, and a stale basemap can make correct new data look wrong.", "example": "In the review interface, each predicted footprint appears as a red polygon over an imagery basemap. A reviewer flips the basemap to the OSM cartographic layer for a second opinion — the 'building' the model found is already mapped there as a water tank, and the prediction is rejected in one glance.", "related": [ "map-tile", "openstreetmap", "maplibre", "imagery-licensing", "review-ui" ], "source": "wiki.openstreetmap.org — Slippy map tilenames / Zoom levels" }, { "slug": "benchmark", "term": "Benchmark", "aka": [ "Benchmark Dataset", "Public Test Set" ], "category": "evaluation", "short": "A fixed public test everyone runs, enabling fair comparison — until the field starts overfitting to it.", "definition": "A benchmark is a fixed, shared evaluation: the same data, the same metrics, the same rules for everyone, so results from different teams and years are comparable. Benchmarks like the COCO detection suite or building-footprint challenges drove rapid progress by making claims checkable. Their known failure mode is overfitting-to-the-benchmark: once a leaderboard matters, models get tuned — deliberately or through community-wide selection — to that particular dataset's quirks, and scores climb while real-world usefulness stalls. For geo benchmarks there is a second trap: a benchmark drawn from a few well-imaged, well-mapped regions rewards models that work there and says little about the sparse, cloudy, under-mapped places humanitarian work actually targets. Good practice pairs benchmarks with fresh holdout geographies.", "example": "Every team's footprint model scores above 0.90 on a famous benchmark of well-mapped cities. Run on a rural Sahelian district — mud-brick compounds, no benchmark lookalike — the same models scatter between 0.45 and 0.75. The benchmark measured the benchmark.", "related": [ "holdout", "f1-score", "intersection-over-union", "ground-truth", "spatially-honest-evaluation" ], "source": "COCO detection evaluation (cocodataset.org); Roberts et al. 2017 — Cross-validation strategies…, Ecography 40:913-929 (geographic transfer caveat); standard treatment of benchmark overfitting in the ML literature" }, { "slug": "building-footprint", "term": "Building Footprint", "aka": [ "footprint" ], "category": "models", "short": "The polygon outline of a building on the ground — the bread-and-butter output of humanitarian mapping.", "definition": "A building footprint is the polygon tracing a building's outline as seen from above — the fundamental unit of humanitarian mapping, because footprints drive population estimates, vaccination campaign planning, and disaster damage assessment. Humans draw them by tracing rooflines in imagery; models produce them by segmenting roof pixels and vectorizing the mask into a polygon. Footprints derived from imagery inherit small distortions — a tall building's roof is offset from its true ground position unless the image is orthorectified — and machine-made footprints are notoriously blobby at corners, which is why AI-generated footprints go through human review before entering OpenStreetMap.", "example": "After a cyclone, responders need to know how many structures existed in a coastal district. A model proposes 40,000 footprints from pre-event imagery; mappers validate and correct them; the resulting OSM polygons become the denominator for damage assessment against post-event imagery.", "related": [ "semantic-segmentation", "openstreetmap", "humanitarian-mapping", "orthorectification", "review" ], "source": "hotosm fAIr documentation (github.com/hotosm/fAIr); qukaizen-geoai/docs/LANDSCAPE.md (first release built around building footprints)" }, { "slug": "bundle-manifest", "term": "Bundle manifest", "aka": [ "geoai.bundle-manifest/v1alpha1" ], "category": "runtime", "short": "The record of every input in a bundle, each pinned by digest — the trust boundary's paperwork.", "definition": "The bundle manifest is the machine-readable record of every input in an inference bundle, each pinned by cryptographic digest — the paperwork that makes the trust boundary checkable. The geoai.bundle-manifest/v1alpha1 schema (a shipped draft; its verifier is the first M1 build item) declares: a bundle_id digest; each imagery asset with path, digest, media type, and optional provenance (STAC item, bounding box, acquisition time, license, attribution); geometry files by digest; the task definition by digest; the model by id, digest, and store reference; and the policy file by digest. Verification is specified to be exhaustive: any file present but undeclared, or declared but hash-mismatched, rejects the whole bundle. The provenance fields carry the licensing discipline — imagery, labels, and model provenance are recorded separately.", "example": "The worked example declares a post-event GeoTIFF with digest sha256:19c8..., its OpenAerialMap STAC item id, a CC-BY-4.0 license, and attribution — so six months later, anyone can answer 'what imagery, under what license, produced this prediction?' from the manifest alone.", "related": [ "inference-bundle", "content-addressing", "sha-256", "verify-bundle", "imagery-licensing" ], "source": "qukaizen-geoai/schemas/geoai.bundle-manifest.v1alpha1.schema.json; qukaizen-geoai/schemas/examples/bundle-manifest.example.json; qukaizen-geoai/docs/ROADMAP.md (M1 item 1)" }, { "slug": "calibration", "term": "Calibration", "aka": [ "Confidence Calibration" ], "category": "evaluation", "short": "Do the model's confidence scores mean what they say — is a 0.9 right about 90% of the time?", "definition": "Calibration asks whether a model's confidence scores are honest: among all predictions scored 0.9, roughly 90% should be correct. A model can rank well (its high scores are more often right than its low scores) while its numbers are still wrong as probabilities. Guo et al. showed modern neural networks are typically overconfident — a deep net's '0.95' may be right only 80% of the time. This matters wherever scores drive decisions: triaging which predictions humans review first, or auto-accepting anything above a threshold. Miscalibration can be measured (reliability diagrams, expected calibration error) and partly corrected with simple post-hoc fixes like temperature scaling. Calibration can also drift by geography — scores honest in one region may be inflated in another.", "example": "A review queue trusts anything the building detector scores above 0.95. Auditing a sample shows those 'near-certain' flags are right only 82% of the time in one desert region — thousands of confident false positives would have skipped human eyes entirely.", "related": [ "model-score", "human-in-the-loop", "review", "hallucination" ], "source": "arXiv:1706.04599 — On Calibration of Modern Neural Networks (Guo et al.)" }, { "slug": "changeset", "term": "Changeset", "category": "mission", "short": "OSM's unit of contribution: a bundle of edits saved together with a comment, attributable to one mapper and reviewable by anyone.", "definition": "A changeset is OpenStreetMap's unit of contribution: when a mapper saves their work, all the edits go in together as one bundle, stamped with their username, a timestamp, the editing software used, the imagery source, and a comment describing what they did. Changesets make OSM auditable. Every building and road on the map traces back to specific changesets, so anyone can see who added what, when, and why — and anyone can comment on a changeset to ask questions or flag problems. Bad edits can be reverted changeset by changeset. This attribution-and-review fabric is why the humanitarian ecosystem insists AI predictions pass through human mappers: whatever enters OSM must have a human contributor standing behind the changeset.", "example": "A validator reviewing a new mapper's work opens their latest changeset: 'Added 46 buildings near Gulu, HOT task #4412, Maxar imagery.' She spots three squares traced around shadows instead of roofs, leaves a friendly changeset comment explaining the difference, and the newcomer fixes them the same evening.", "related": [ "openstreetmap", "mapper", "validate", "human-in-the-loop" ], "source": "wiki.openstreetmap.org — Changeset; openstreetmap.org" }, { "slug": "cloud-cover", "term": "Cloud cover", "aka": [ "Cloudiness" ], "category": "imagery", "short": "The perennial enemy of optical imaging: clouds hide the ground, so usable scenes are scarcer than passes.", "definition": "Cloud cover is the fraction of an optical satellite scene obscured by clouds — and the single biggest reason 'the satellite flew over' does not mean 'we have imagery.' Optical sensors see reflected sunlight, so clouds and their shadows simply replace the ground in the data. Since much of Earth is cloudy at any moment, and rainy seasons in the tropics can stay overcast for months, usable scenes are far scarcer than satellite passes. Every scene's metadata therefore records an estimated cloud percentage, and pipelines filter on it (say, under 10%) or composite the clear pixels of many dates into one cloud-free mosaic. Radar sensors see through clouds, but the optical imagery that mapping depends on does not.", "example": "A monsoon-season flood hits, and coordinators wait for imagery. Pass after pass returns scenes flagged 95% cloud — white sheets where the delta should be. Twelve days later a brief clear window yields one 8%-cloud scene, and the flood map that follows is built entirely from that single lucky acquisition.", "related": [ "satellite-imagery", "sentinel-2", "landsat", "earth-observation" ], "source": "ESA Sentinel Online — Copernicus Sentinel-2 documentation; NASA Landsat science (landsat.gsfc.nasa.gov)" }, { "slug": "cloud-optimized-geotiff", "term": "Cloud Optimized GeoTIFF", "aka": [ "COG" ], "category": "imagery", "short": "COG: a GeoTIFF laid out so clients can HTTP range-request just the window and zoom they need.", "definition": "A Cloud Optimized GeoTIFF is a regular GeoTIFF whose internal bytes are arranged for efficient partial reading over the network. The pixels are stored as internal tiles rather than long strips, reduced-resolution overviews are embedded, and the layout is ordered so a client can issue plain HTTP range requests to fetch only the tiles and zoom level covering its window of interest. The payoff: a 50 GB country-scale mosaic can sit on ordinary object storage, and a reviewer inspecting one village downloads a few megabytes. It is still a valid GeoTIFF — any reader opens it — formalized as OGC 21-026. COGs are how modern pipelines avoid copying whole scenes around.", "example": "A review tool needs to show a 300-meter neighborhood from a nationwide 40 GB mosaic hosted in cloud storage. Because the mosaic is a COG, the viewer range-requests roughly 4 MB — the overviews plus the handful of internal tiles under the viewport — and renders in about a second.", "related": [ "geotiff", "raster-data", "map-tile" ], "source": "cogeo.org / OGC 21-026 (Cloud Optimized GeoTIFF); OGC GeoTIFF 1.1 (OGC 19-008r4)" }, { "slug": "computer-vision", "term": "Computer Vision", "aka": [ "CV" ], "category": "models", "short": "The field of teaching machines to interpret images — the umbrella over segmentation, detection, and classification.", "definition": "Computer vision is the branch of AI concerned with getting machines to make sense of pictures. It is an umbrella over many task types defined by what the output looks like: classification (one label per image), object detection (boxes around things), semantic segmentation (a label for every pixel), and instance segmentation (separate masks per object). In humanitarian mapping the inputs are satellite or aerial tiles and the outputs are usually building or road geometry. Modern computer vision is dominated by deep neural networks trained on labeled examples, which is why label quality and provenance matter as much as model architecture.", "example": "A MapSwipe project is a computer-vision classification task run by humans: 'does this tile contain a building — yes, maybe, or no?' The model-side equivalent asks a trained network the same question about millions of tiles, then routes the uncertain ones back to people.", "related": [ "semantic-segmentation", "object-detection", "satellite-imagery", "ai-assisted-mapping" ], "source": "hotosm fAIr documentation (github.com/hotosm/fAIr); qukaizen-geoai/docs/LANDSCAPE.md (model landscape survey)" }, { "slug": "confusion-matrix", "term": "Confusion Matrix", "aka": [ "Error Matrix", "Contingency Table" ], "category": "evaluation", "short": "The 2×2 table of hits, false alarms, misses, and correct rejections that every other metric is computed from.", "definition": "A confusion matrix is the bookkeeping table behind classification metrics. For a yes/no question like 'does this tile contain buildings?' it has four cells: true positives (said yes, was yes), false positives (said yes, was no — false alarms), false negatives (said no, was yes — misses), and true negatives (said no, was no). Precision, recall, F1, and accuracy are all arithmetic on these four counts, so when a headline number looks odd, the matrix is where you look. It generalizes to more classes (building / road / water), where off-diagonal cells reveal which categories the model confuses — remote sensing has used it as the 'error matrix' for decades.", "example": "A MapSwipe-style run over 1,000 tiles yields TP=180, FP=45, FN=20, TN=755. Reading the matrix directly: precision 180/225 = 0.80, recall 180/200 = 0.90, and the 45 false alarms turn out to be mostly cloud shadow on bare rock — a fixable confusion.", "related": [ "precision", "recall", "f1-score", "mapswipe" ], "source": "Standard statistics and remote-sensing accuracy assessment (Congalton & Green, Assessing the Accuracy of Remotely Sensed Data); standard machine-learning textbook treatment" }, { "slug": "constrained-generation", "term": "Constrained Generation", "aka": [ "structured output", "grammar-constrained decoding" ], "category": "models", "short": "Forcing a language model's output to match a schema or grammar, so downstream code can trust its shape.", "definition": "Constrained generation makes it impossible for a language model to produce output that violates a required format. Instead of asking nicely for JSON and hoping, the runtime masks the model's token choices at every step: any token that would break the grammar is given zero probability, so the output is valid by construction. This converts a chatty text generator into a component whose output a parser can trust — essential when a verdict must be exactly one of yes/maybe/no plus a score, not an essay. The guarantee is about shape, not truth: a constrained model can still be confidently wrong, just in a machine-readable way. It is qukaizen-geoai's v0 design mechanism for verdicts, via llama.cpp and GBNF.", "example": "Unconstrained, the verdict model replies 'I believe there is likely a building here, though shadows make it…' — unparseable. Constrained by the World's grammar, the only strings it can physically emit look like {\"verdict\":\"yes\",\"score\":0.82}, every time, for a million tiles.", "related": [ "gbnf", "llama-cpp", "prediction-record", "hallucination" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (constrained verdict engine, v0 design); llama.cpp grammars/README.md (github.com/ggml-org/llama.cpp)" }, { "slug": "content-addressing", "term": "Content addressing", "aka": [ "Content-addressed storage" ], "category": "runtime", "short": "Naming things by the hash of their bytes, so the name itself proves the content.", "definition": "Content addressing means naming a piece of data by the cryptographic hash of its bytes instead of by a location or filename. The name then proves the content: if you have the name sha256:19c8... and a file, you can recompute the hash and know with cryptographic certainty whether it is the right file — no trust in the storage, the transport, or the person who handed it over. It also makes data naturally immutable (changing one byte changes the name) and deduplicated (identical content has identical names). qukaizen-geoai's design uses it everywhere: bundle assets are stored under their digests, model weights live in a shared content-addressed store mounted read-only, and receipts chain digests together so an entire run is reconstructible from names alone.", "example": "Two projects both need the same 400 MB Qwen3 model artifact. Because the model store is content-addressed, it exists once on disk under its digest; each bundle merely references sha256:6c22... and the worker verifies the mounted weights match before loading them.", "related": [ "sha-256", "inference-bundle", "bundle-manifest", "determinism" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§2: content-addressed assets and shared model store); qukaizen-geoai/schemas/examples/bundle-manifest.example.json" }, { "slug": "control-plane", "term": "Control plane", "category": "stack", "short": "The online half of the system: manifests, acquisition, licenses, splits, and run declarations — owned by DaC, never by inference.", "definition": "The control plane is the part of the system that is allowed to talk to the world. Owned by qukaizen-dac, it holds dataset manifests, asset acquisition (fetching and hashing imagery), license and provenance records, geographic train/test splits, task definitions, model selection, run declarations, and the policy for reviewing and exporting results. It may use the network during explicit acquire and publish phases — and inference never does. That split is the design's core safety idea: by the time anything reaches the execution plane, every URL and credential is gone, replaced by content-addressed local files. The control plane also validates results afterward: calibration, abstention, human review, and the explicit export decision all happen here, never inside the sandbox.", "example": "Before a Mozambique road-obstruction run, the control plane fetches the imagery, records each tile's license and SHA-256, draws the spatial split, and writes the run declaration. Only then does it build the bundle the offline side will execute — with the network already out of the picture.", "related": [ "execution-plane", "data-as-code", "dac-manifest", "inference-run", "acquire" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md §1 and repo-ownership table; qukaizen-geoai/docs/decisions/0001-repo-boundaries-and-pinned-contracts.md Decision 2" }, { "slug": "coordinate-reference-system", "term": "Coordinate reference system", "aka": [ "CRS", "Spatial reference system", "SRS" ], "category": "imagery", "short": "CRS: the agreed convention for what coordinate numbers mean — datum, projection, units, EPSG code.", "definition": "A coordinate reference system is the agreement that gives coordinate numbers meaning. Saying a building is at (36.82, -1.29) is useless until you state the convention: which model of Earth's shape (the datum, usually WGS 84), whether the numbers are angles on the globe or meters on a flattened projection, and in what order and units. Each standard combination has an identifier in the EPSG registry — EPSG:4326 for plain WGS 84 latitude/longitude, EPSG:3857 for Web Mercator. Mixing CRSs silently is a classic geospatial bug: data appears hundreds of kilometers off or vanishes entirely. Every serious geospatial file and API therefore declares its CRS explicitly.", "example": "A new contributor loads model predictions over imagery and every building sits in the ocean off West Africa. The predictions were in Web Mercator meters; the viewer assumed degrees. One line declaring the correct EPSG code, and thousands of buildings snap from the Atlantic back onto their city.", "related": [ "web-mercator", "georeferencing", "geojson", "geotiff" ], "source": "EPSG:3857 registry (epsg.org); IETF RFC 7946 — The GeoJSON Format" }, { "slug": "crowdsourcing", "term": "Crowdsourcing", "category": "mission", "short": "Many volunteers each make small judgments; redundancy and agreement turn those judgments into reliable data.", "definition": "Crowdsourcing is the pattern of splitting a huge task into many small judgments, distributing them to volunteers, and aggregating the answers into reliable data. Its power comes from redundancy: no single volunteer needs to be an expert, because each imagery tile or building is shown to several people independently, and agreement between them signals confidence. Where volunteers disagree, that disagreement is itself valuable information — it flags genuinely ambiguous cases for expert review. MapSwipe is a textbook example: each tile is classified by multiple swipers before it counts. The same aggregation logic that validates human judgments also makes crowds a natural quality-control layer for AI predictions, which is why the ecosystem routes model outputs through volunteer review rather than around it.", "example": "Six volunteers independently see the same imagery tile. Five tap 'building', one taps 'maybe' — the tile is confidently marked as settled. On the next tile the votes split three against three: that tile goes to an experienced validator, because the crowd just discovered it is genuinely hard.", "related": [ "mapswipe", "mapper", "human-in-the-loop", "validate", "ground-truth" ], "source": "mapswipe.org — how it works; qukaizen-geoai/docs/LANDSCAPE.md (human judgment layer, metrics that matter)" }, { "slug": "dac-manifest", "term": "dac.manifest/v2", "aka": [ "Dataset manifest" ], "category": "stack", "short": "The dataset contract: which assets, under which licenses, with which digests and splits — pinned as spec from dac ADR-0005.", "definition": "dac.manifest/v2 is the contract that describes a dataset as code: what assets it contains, which licenses cover each one, what content digests prove they are unmodified, and which spatial splits divide them into train and evaluation geography. It is authored and owned by qukaizen-dac; qukaizen-geoai only consumes it, never forks it. Status honesty: the v2 schema lives in dac ADR-0005 on the branch qukaizen/dac-inference-engines-90e408, unmerged as of 2026-07-12. Per geoai ADR-0001 the contract is pinned as spec — geoai records the version it validates against, does not block on the merge, and does not silently drift; if the branch lands changed, the pin is updated deliberately.", "example": "A manifest for a July 2026 Mozambique dataset lists every imagery tile with its SHA-256, records that the tiles are commercially licensed while any derived polygons may be opened, and names the spatial split that keeps evaluation districts out of training geography.", "related": [ "control-plane", "inference-run", "imagery-licensing", "spatial-split", "sha-256" ], "source": "qukaizen-geoai/docs/decisions/0001-repo-boundaries-and-pinned-contracts.md Decision 3; qukaizen-geoai/docs/ARCHITECTURE.md repo-ownership table" }, { "slug": "zero-claw-exec", "term": "dac.zero-claw-exec/v1", "aka": [ "Execution envelope" ], "category": "stack", "short": "The envelope DaC hands to the sandboxed executor: everything already resolved, nothing left that needs a network.", "definition": "dac.zero-claw-exec/v1 is the handoff contract between the two planes: the envelope Data as Code passes to the sandboxed executor when it dispatches a run. Its defining property is total resolution — by the time the envelope crosses the boundary, every asset is a local content-addressed file, every model is a digest-pinned artifact, and no URL, credential, or unresolved reference remains. The name carries dac's coined image: a container with no claws cannot reach out and grab anything. Status honesty: this is a dac-owned contract on the unmerged ADR-0005 branch, consumed by geoai as pinned spec (ADR-0001). geoai's own dispatch-request draft (geoai.dispatch/v1alpha1) pins bundle and sandbox profile by digest in the same spirit; the executor itself is ROADMAP.", "example": "Imagine mailing a chef a sealed crate containing every ingredient, the full recipe, and the exact pan — with the kitchen's phone line cut. The chef can cook or refuse, but cannot call out for substitutions. That crate is the envelope.", "related": [ "inference-bundle", "secure-zero-egress-claw", "control-plane", "content-addressing" ], "source": "qukaizen-geoai/docs/decisions/0001-repo-boundaries-and-pinned-contracts.md (pinned contracts, zero-claw lineage); qukaizen-geoai/docs/ARCHITECTURE.md §§3–4" }, { "slug": "data-as-code", "term": "Data as Code", "aka": [ "DaC", "qukaizen-dac" ], "category": "stack", "short": "The philosophy and engine that treats knowledge and datasets like code: declared, versioned, gated, and reproducible.", "definition": "Data as Code is the idea that datasets and knowledge should be handled the way good engineers handle code: declared in files, versioned, checked by an automated gate, and rebuildable by anyone. Instead of ad-hoc folders of downloads, a DaC project states what assets it needs, where they came from, what licenses cover them, and what digests prove they are unchanged. The DaC engine that compiles Knowledge Worlds like this one is BUILT and running today. In the GeoAI design, DaC is the control plane: it owns manifests, acquisition, provenance, spatial splits, and run declarations, and it hands the offline execution plane a fully resolved bundle with nothing left to fetch.", "example": "This dictionary you are reading is Data as Code in action: each card sits in a JSON shard with a source, the gate refuses unsourced or dangling entries, and one command recompiles the World. The same discipline, applied to satellite imagery instead of vocabulary, becomes a dataset manifest.", "related": [ "control-plane", "knowledge-world", "provenance-gate", "dac-manifest", "the-loop" ], "source": "qukaizen-dac/data/worlds/README.md; qukaizen-geoai/docs/ARCHITECTURE.md §1 (Data as Code is the control plane)" }, { "slug": "data-leakage", "term": "Data Leakage", "aka": [ "Train-Test Contamination", "Leakage" ], "category": "evaluation", "short": "When evaluation data secretly informs training, inflating scores — in geography, mere adjacency is leakage.", "definition": "Data leakage is any path by which information from the evaluation set sneaks into training, making scores look better than the model really is. Classic forms include duplicated records on both sides of a split, or preprocessing (like normalization statistics) computed over all the data before splitting. Geography adds a subtler form: because nearby places resemble each other, a tile adjacent to a training tile is nearly a duplicate even though no file was shared — adjacency itself is leakage. Leakage is insidious because everything looks procedurally correct; the tell is a model that aces evaluation and stumbles in deployment. Defenses are structural: split by place, buffer the boundary, deduplicate imagery, and record the split so it can be audited.", "example": "A team randomly splits a city's tiles and reports 0.93 F1. Deployed one country over, the model falls to 0.60. The random split had trained on tiles a few hundred meters from every test tile — the model had learned that city's rooftops, not buildings in general.", "related": [ "spatial-autocorrelation", "spatial-split", "spatially-honest-evaluation", "holdout" ], "source": "Roberts et al. 2017 — Cross-validation strategies…, Ecography 40:913-929; standard machine-learning practice (Kaufman et al. 2012, Leakage in Data Mining, TKDD)" }, { "slug": "determinism", "term": "Determinism", "aka": [ "Reproducible inference" ], "category": "runtime", "short": "Same bundle + same profile ⇒ byte-identical predictions digest — or the divergence is documented in the receipt.", "definition": "Determinism here means running the same inference bundle under the same sandbox profile is specified to produce a byte-identical predictions file — same digest — or, where that cannot be guaranteed, the divergence is documented in the receipt rather than hidden. Reproducibility is a trust feature: a prediction may influence where aid goes, and 'run it again and check' is the cheapest audit there is — but only if reruns are comparable. The design pursues it through deterministic preprocessing, seeded sampling, a worker with no agent loop, and recording the exact engine build and parameters in the receipt. Honest caveat, stated in the roadmap: QueueLLM's determinism contract (its ADR 0019) is still Proposed, so M1's check records engine build and parameters either way, treating divergence as reportable, not deniable.", "example": "The M1 acceptance test runs one bundle twice on the same machine and compares output digests. If sha256 of predictions.ndjson matches, determinism held. If GPU scheduling introduced a difference, the receipts carry enough detail — engine build, sampling parameters — to explain exactly why, in writing.", "related": [ "content-addressing", "execution-receipt", "sha-256", "inference-bundle" ], "source": "qukaizen-geoai/CLAUDE.md (gating: determinism); qukaizen-geoai/docs/ROADMAP.md (M1 item 4); qukaizen-geoai/docs/ARCHITECTURE.md (§4 deterministic worker)" }, { "slug": "docent", "term": "Docent", "category": "stack", "short": "Each World's teaching guide: a grounded assistant that answers only within the World's scope, anchored to its compiled corpus.", "definition": "A docent — the word museums use for a guide — is the assistant attached to a Knowledge World. Instead of answering from a general model's open-ended memory, the docent is anchored to the World's compiled terms.json: it retrieves the gate-passed cards and answers inside that scope, citing the cards' own sources. This keeps it honest about the World's declared gaps rather than papering over them. The retrieval-grounded docent is BUILT and live in DaC today, serving over compiled Worlds. The roadmap ambition is to graduate a docent from retrieval into weights via a Nucleus bake, so the knowledge lives in the model itself — that baked form is the destination, not the shipped state.", "example": "Ask this World's docent 'what is zero egress?' and it answers from the zero-egress card and its neighbors, with sources. Ask it about French cooking and it should decline — that universe belongs to a different World.", "related": [ "knowledge-world", "provenance-gate", "arail", "nucleus" ], "source": "qukaizen-dac/VISION.md (docent persona, RAG-live / bake-roadmap honesty line); qukaizen-dac/data/worlds/README.md" }, { "slug": "earth-observation", "term": "Earth observation", "aka": [ "EO" ], "category": "imagery", "short": "The whole discipline and industry of systematically monitoring Earth from space and air.", "definition": "Earth observation is the broad enterprise of monitoring the planet with remote sensors — the missions, agencies, companies, archives, and science built around it. Where remote sensing names the measurement technique, earth observation names the field: public programs like NASA/USGS Landsat and Europe's Copernicus that publish free imagery of the whole planet on a fixed schedule, commercial constellations selling very-high-resolution scenes, and the processing ecosystems around them. For humanitarian GeoAI the key fact is that the public side of this industry made planetary-scale, free, openly licensed imagery a baseline — which is what allows open mapping projects to exist at all.", "example": "When someone asks why a small nonprofit can get fresh imagery of a remote district for free, the answer is decades of public earth observation: Copernicus and Landsat fly regardless of who is watching, and their archives are open to anyone with an internet connection.", "related": [ "remote-sensing", "sentinel-2", "landsat", "satellite-imagery" ], "source": "NASA Landsat science (landsat.gsfc.nasa.gov); ESA Sentinel Online — Copernicus Sentinel-2 documentation" }, { "slug": "egress", "term": "Egress", "aka": [ "Data egress", "Network egress" ], "category": "runtime", "short": "Data leaving a machine, by any channel — DNS lookups, HTTP requests, UDP packets, even crash reporters all count.", "definition": "Egress is any data leaving a machine, and the honest accounting counts every channel, not just obvious file uploads. An HTTP POST is egress; so is a DNS lookup (the queried hostname itself leaks information), a UDP packet, a connection to localhost services that relay onward, traffic routed through a proxy set in environment variables, and background telemetry or error reporters bundled inside libraries. Software 'phones home' constantly by default, which is why qukaizen-geoai treats egress as something to be denied at the platform level and then adversarially disproven, rather than trusted to application-level configuration. The design's egress test suite enumerates these channels explicitly so that 'no egress' means all of them, not just the polite ones.", "example": "A well-meaning Python library, imported for image decoding, quietly checks for updates on startup. That single DNS query plus HTTPS GET is egress — invisible in the application's own code, but exactly the kind of channel the adversarial suite is designed to catch and the sandbox profile is specified to deny.", "related": [ "zero-egress", "egress-test-suite", "sandbox", "telemetry", "metadata-endpoint" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§3 egress test enumeration: DNS, IPv4/IPv6 TCP, UDP, loopback, proxy env vars, metadata IPs)" }, { "slug": "egress-test-suite", "term": "Egress test suite", "aka": [ "Adversarial egress tests", "Network verification suite" ], "category": "runtime", "short": "The adversarial proof of zero egress: every escape channel is actively attempted from inside the sandbox, and every attempt must fail.", "definition": "The egress test suite is how zero egress gets proven instead of assumed: a battery of adversarial tests that runs inside the sandbox and actively attempts every known escape channel, requiring each to fail. The design enumerates the attempts: DNS resolution; IPv4 and IPv6 TCP connections; UDP; loopback access; Unix-socket escape beyond the single dispatcher socket; honoring proxy environment variables like HTTP_PROXY; reaching cloud metadata IPs (169.254.169.254); inherited file descriptors; subprocess creation; reading SSH configuration, browser cookies, and home directories; writing outside the output directory; and symlink traversal out of the bundle. The result lands in the receipt's network_verification field, and a failed verification is specified to abort the run. This is repo-gating and a core M1 deliverable — design stage today, targeting the macOS Seatbelt backend first.", "example": "The suite runs under a candidate Seatbelt profile: DNS times out, connect() to 1.1.1.1:443 is refused, fork() fails, opening ~/.ssh/config is denied, a symlink pointing at /etc is not followed. Twelve attacks, twelve failures — and only then does the receipt read network_verification: 'passed'.", "related": [ "zero-egress", "egress", "metadata-endpoint", "execution-receipt", "secure-zero-egress-claw" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§3 'Prove zero egress rather than merely configuring it'); qukaizen-geoai/CLAUDE.md (gating); qukaizen-geoai/schemas/geoai.receipt.v1alpha1.schema.json (sandbox.network_verification)" }, { "slug": "enforcement-level", "term": "Enforcement level", "aka": [ "Isolation level" ], "category": "runtime", "short": "How strongly isolation actually held — strict, enforced, or best-effort — recorded in the receipt; below 'enforced' the run must refuse.", "definition": "The enforcement level names how strongly the sandbox's isolation actually held, as opposed to what was requested. The design defines three tiers: 'strict' means the OS or VM proves no network namespace or virtual network card exists at all; 'enforced' means process-level policy denies network syscalls and outbound connections; 'best-effort' means only the application promised to behave — which the profile refuses outright. The level achieved is recorded in the execution receipt, and the receipt schema deliberately makes best-effort inexpressible: its enforcement_level field allows only 'strict' or 'enforced'. This turns a security posture into a verifiable field: a reviewer never has to guess whether isolation was real, and a silently weakened run cannot produce a valid receipt.", "example": "On a Linux box without namespace privileges, the runtime can only offer application-level network denial — best-effort. Under the design, the run refuses to start rather than proceed; there is no receipt because there was no run. On a Mac with Seatbelt active, the same bundle runs and the receipt records enforcement_level: 'enforced'.", "related": [ "fail-closed", "execution-receipt", "sandbox-profile", "secure-zero-egress-claw" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§3 enforcement levels); qukaizen-geoai/schemas/geoai.receipt.v1alpha1.schema.json (sandbox.enforcement_level enum)" }, { "slug": "execution-plane", "term": "Execution plane", "category": "stack", "short": "The offline half owned by qukaizen-geoai: verify the bundle, seal the sandbox, run the deterministic worker, emit a receipt.", "definition": "The execution plane is the part of the system that runs the model — and is forbidden from touching the network at all. Owned by qukaizen-geoai, its design has four stages: verify an immutable inference bundle (every input content-addressed, no URLs), confine execution inside the secure-zero-egress-claw sandbox profile, run a deterministic inference worker with no agent loop, and emit an execution receipt proving what actually ran. Honesty note: this is the M0 design — the schemas are drafted and the architecture is written, but the runtime, sandbox enforcement, and worker are ROADMAP, not shipped code. The boundary itself is fixed by ADR-0001: this plane never acquires assets and never publishes; those verbs belong to the control plane.", "example": "Picture a sealed room: the bundle is wheeled in, the door locks, the model reads imagery and writes predictions, a receipt is stamped, and the door opens. Nothing inside ever dialed out — and the receipt records the proof that it could not.", "related": [ "control-plane", "geoai-runtime", "zero-egress", "sandbox", "execution-receipt" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md §§2–4; qukaizen-geoai/CLAUDE.md (M0 status); qukaizen-geoai/docs/decisions/0001-repo-boundaries-and-pinned-contracts.md" }, { "slug": "execution-receipt", "term": "Execution receipt", "aka": [ "Run receipt", "geoai.receipt/v1alpha1" ], "category": "runtime", "short": "The record proving what actually executed: bundle, model, and task digests, engine build, enforcement level, egress-audit result, timings.", "definition": "The execution receipt is the record every run is specified to produce, proving what actually executed rather than what was intended. The geoai.receipt/v1alpha1 schema (shipped as a draft with a worked example; production is an M1 build item) requires: the bundle, model, and task digests; the engine's name, version, and build; the sandbox section with profile name, version, digest, platform backend, enforcement level, network status (constant 'denied'), and the egress-verification result; the output digest; and start/finish timestamps. Optionally it records hardware and — from M3 — a signature over the digest chain, giving tamper evidence when results move between machines. A receipt proves provenance and isolation, deliberately not that the prediction is correct. Its design builds on QueueLLM's replay-bundle record (BUILT), which already fingerprints model, prompt, and sampling per generation.", "example": "A reviewer questioning a flood-damage result opens receipt.json: bundle sha256:87af..., aerollm 0.1.0 build git:4c1d0000, Seatbelt backend, enforcement 'enforced', network_verification 'passed', six minutes wall time. Every claim in that audit trail is a checkable digest, not a promise.", "related": [ "sha-256", "enforcement-level", "egress-test-suite", "determinism", "prediction-record" ], "source": "qukaizen-geoai/schemas/geoai.receipt.v1alpha1.schema.json; qukaizen-geoai/schemas/examples/receipt.example.json; qukaizen-geoai/docs/ARCHITECTURE.md ('Execution receipt')" }, { "slug": "export", "term": "Export", "aka": [ "dac export", "Publish stage" ], "category": "loop", "short": "The only online exit: an explicit, human-approved packaging step, gated on four maintainer agreements before any adapter ships.", "definition": "Export is the only door back to the internet, and it opens only on explicit human approval. The designed command — `dac export run_… --format mapswipe-review-package` — packages a reviewed run for handoff to the MapSwipe community, as a deliberately separate phase from inference: no single process may acquire, infer, and publish. The MapSwipe/fAIr export adapters are this repo's sole volunteer-facing artifact, and they are doubly gated: build-wise on M3 (after M2 results exist and review is enforced), and community-wise on four concrete maintainer agreements (COMMUNITY.md A1–A4: upstream code boundary, ethical use of a live project, an export format preserving individual-vote signal, and license clarity). MapSwipe and HOT are independent communities; nothing ships to them without their agreement. All of this is ROADMAP.", "example": "The Malawi run is reviewed and ready, but no maintainer agreement exists yet — so the adapter simply does not exist to run. Once the boundary is agreed, the operator will run one explicit export command, see exactly what the package contains, and approve it; predictions never drift onto the network as a side effect.", "related": [ "review", "validate", "mapswipe", "fair", "provenance-gate" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (\"Developer CLI\"); docs/ROADMAP.md M3 and community track; docs/COMMUNITY.md §1 (agreements A1–A4); read 2026-07-12" }, { "slug": "f1-score", "term": "F1 Score", "aka": [ "F-measure", "Harmonic Mean of Precision and Recall" ], "category": "evaluation", "short": "The harmonic balance of precision and recall in one number — handy for ranking, dangerous for hiding trade-offs.", "definition": "The F1 score squeezes precision and recall into a single number: their harmonic mean, 2PR/(P+R). The harmonic mean punishes imbalance — a model with 0.99 precision and 0.10 recall gets F1 ≈ 0.18, not the flattering 0.55 an ordinary average would give. One number helps when comparing many models or tracking progress over time. It hides things when the two error types have different real-world costs: F1 weighs a missed village and a false alarm equally, which no field coordinator would. It also says nothing about where errors fall geographically. Use F1 to rank; read precision, recall, and a map of errors before trusting a model.", "example": "Two building detectors both score F1 = 0.80. One misses remote hamlets but is clean in towns; the other finds every hamlet but litters towns with false flags. Identical number, opposite failure modes — the mapathon coordinator needs the second model, and only the breakdown reveals it.", "related": [ "precision", "recall", "confusion-matrix", "benchmark" ], "source": "van Rijsbergen, Information Retrieval, 1979 (F-measure origin); standard machine-learning textbook treatment (e.g., Manning et al., Introduction to Information Retrieval)" }, { "slug": "fail-closed", "term": "Fail closed", "aka": [ "Fail-safe default" ], "category": "runtime", "short": "When unsure, stop: the design refuses to run rather than silently downgrading to weaker isolation.", "definition": "Fail-closed is the design rule that when the system cannot guarantee its security promise, it stops rather than proceeding with a weaker one. The opposite — fail-open — degrades gracefully and quietly, which is exactly wrong for a security boundary: a sandbox that 'mostly works' is indistinguishable from one that works, until it matters. In qukaizen-geoai the rule is concrete and repo-gating: if the platform cannot provide at least 'enforced' isolation, the run is specified to refuse to start; no code may silently downgrade to best-effort; and the enforcement level actually achieved lands in the receipt so the claim is checkable afterward. The sandbox-profile schema encodes this as enforcement.failClosed: true with minimumLevel 'enforced'. Design stage — first enforced in the M1 build.", "example": "A volunteer runs the toolkit inside an unusual container that blocks the Seatbelt sandbox facility. Instead of shrugging and running anyway with an app-level 'please don't network' flag, the worker exits with an error explaining that isolation could not be established. Annoying for five minutes; honest forever.", "related": [ "enforcement-level", "secure-zero-egress-claw", "sandbox-profile", "execution-receipt" ], "source": "qukaizen-geoai/CLAUDE.md (conventions: 'Fail closed'); qukaizen-geoai/docs/ARCHITECTURE.md (§3: 'Never silently downgrade to best-effort'); qukaizen-geoai/schemas/geoai.sandbox-profile.v1alpha1.schema.json" }, { "slug": "fair", "term": "fAIr", "category": "mission", "short": "HOT's open AI-assisted mapping service: it trains localized building-detection models on community-validated labels.", "definition": "fAIr is the Humanitarian OpenStreetMap Team's open-source AI-assisted mapping service. Instead of one global model, it trains localized models: a community selects a well-mapped training area, fAIr fetches the OSM labels and licensed imagery for it, trains a building-detection model tuned to that region's roofs and settlement patterns, and runs predictions that mappers then review. Shipped capabilities include reproducible models, offline predictions, geometry post-processing, and fAIrSwipe, which routes predictions into MapSwipe for human validation. fAIr is AGPL-licensed and independently maintained by HOT; its roadmap is ambitious and should not be confused with deployed functionality. QuKaiZen's geoai project consumes its public artifacts and hopes to contribute evaluation evidence upstream — nothing more.", "example": "A mapping community in Tanzania trains a fAIr model on their own validated neighborhood. The model then proposes building outlines across the unmapped districts nearby — round thatched roofs and all, because it learned from local examples rather than American suburbs — and mappers accept, fix, or reject each proposal.", "related": [ "hot", "mapswipe", "ai-assisted-mapping", "training-label", "building-footprint" ], "source": "github.com/hotosm/fAIr; hotosm.org — fAIr product page; qukaizen-geoai/docs/LANDSCAPE.md (fAIr is the model production layer)" }, { "slug": "fine-tuning", "term": "Fine-Tuning", "aka": [ "transfer learning", "adaptation" ], "category": "models", "short": "Adapting a pretrained model to a specific domain or region with a modest amount of new labeled data.", "definition": "Fine-tuning takes a model already trained on a large general dataset and continues training it briefly on a small, specific one, so it adapts to a new domain without learning vision from scratch. It works because most of what a building detector needs — edges, textures, shadows — transfers across geographies; only the local specifics need adjusting. This matters enormously in humanitarian mapping because roofs in rural Niger look nothing like roofs in suburban Manila: fAIr's core workflow is exactly this, letting communities fine-tune a baseline building detector on their own region's imagery and freshly mapped OSM labels, producing a localized model from hundreds rather than millions of examples.", "example": "A YouthMappers chapter maps 800 buildings across three training areas in their district, then fine-tunes fAIr's baseline on those labels. The regional model stops missing thatched circular roofs the global baseline had never really seen.", "related": [ "fair", "training-label", "specialist-model", "youthmappers" ], "source": "hotosm fAIr documentation (github.com/hotosm/fAIr) — localized model training workflow; qukaizen-geoai/docs/LANDSCAPE.md" }, { "slug": "gbnf", "term": "GBNF", "aka": [ "GGML BNF", "llama.cpp grammar" ], "category": "models", "short": "llama.cpp's grammar format that constrains generation token-by-token — the v0 verdict engine's enforcement mechanism.", "definition": "GBNF (GGML BNF) is llama.cpp's format for writing grammars that constrain what a model may generate. A GBNF file defines production rules — roughly, a strict template language — and at inference time the engine checks every candidate token against the grammar's current state, masking out any that would produce an invalid continuation. Enforcement happens at the logit level, inside the sampling loop, so compliance is mechanical rather than behavioral. In qukaizen-geoai's v0 design, the control plane (dac) compiles a per-World GBNF grammar for the verdict schema, and llama.cpp enforces it; the runtime echoes grammar_applied in each prediction so an unconstrained run can never masquerade as a constrained one.", "example": "The building-verdict grammar allows only: an opening brace, the literal key \"verdict\", one of three enum strings, a score between 0 and 1, a closing brace. When the model wants to emit 'Well,' as its first token, that token's probability is masked to zero — it never leaves the sampler.", "related": [ "constrained-generation", "llama-cpp", "prediction-record", "data-as-code" ], "source": "llama.cpp grammars/README.md (github.com/ggml-org/llama.cpp); qukaizen-geoai/docs/ARCHITECTURE.md (per-World GBNF grammars compiled by dac; grammar_applied echoed)" }, { "slug": "geojson", "term": "GeoJSON", "category": "imagery", "short": "RFC 7946: JSON for geographic geometry — points, lines, polygons with properties — in WGS 84.", "definition": "GeoJSON is a JSON-based format for encoding geographic vector data, standardized as IETF RFC 7946. It defines geometry types — Point, LineString, Polygon and their Multi- variants — plus the Feature (a geometry with a properties object) and FeatureCollection wrappers. The spec fixes coordinates to WGS 84 longitude/latitude order, which removes a whole class of ambiguity. Because it is plain JSON, every programming language, web map, and API reads it natively, making it the default interchange format for footprints, boundaries, and annotations. In this stack it is the shape model predictions take: a predicted building is a GeoJSON polygon with confidence and provenance in its properties.", "example": "The inference worker emits a FeatureCollection: each feature a five-vertex polygon tracing a predicted rooftop, with properties carrying the model's confidence score. The reviewer's browser renders it over imagery with zero conversion, and an accepted feature is already in a format OSM tooling understands.", "related": [ "vector-data", "coordinate-reference-system", "prediction-record", "building-footprint", "openstreetmap" ], "source": "IETF RFC 7946 — The GeoJSON Format" }, { "slug": "georeferencing", "term": "Georeferencing", "category": "imagery", "short": "Pinning an image's pixels to real-world coordinates so software knows where on Earth each pixel sits.", "definition": "Georeferencing is the act of attaching real-world location to an image — declaring which spot on Earth each pixel represents. Mathematically it is a transform from pixel row/column to coordinates in a stated coordinate reference system, typically stored as an origin point plus pixel size (an affine transform) inside a format like GeoTIFF. Once georeferenced, an image can be overlaid with other layers, measured, and aligned with vector data such as OSM buildings. It answers 'where is this?' but not 'is the geometry correct?' — a tilted image can be perfectly georeferenced and still misplace hilltops, which is why orthorectification is a separate step.", "example": "A scanned 1970s district map arrives as a plain image file — historically precious, spatially mute. An archivist marks four road junctions visible in both the scan and modern imagery, the software fits the transform, and suddenly the old map drapes correctly over today's basemap, revealing which villages moved after the dam was built.", "related": [ "coordinate-reference-system", "geotiff", "orthorectification", "raster-data" ], "source": "OGC GeoTIFF 1.1 (OGC 19-008r4); Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "geotiff", "term": "GeoTIFF", "category": "imagery", "short": "TIFF with embedded georeferencing — the workhorse file format for satellite and aerial rasters.", "definition": "GeoTIFF is the standard file format for georeferenced raster data: an ordinary TIFF image carrying extra metadata tags that state where on Earth the pixels belong. The tags encode the coordinate reference system and the transform from pixel positions to map coordinates, so any GIS tool can open the file and place it correctly without side-car files or guesswork. GeoTIFF handles multiple bands, high bit depths, and compression, which is why nearly every satellite scene, drone orthomosaic, and elevation model ships in it. The format is an open OGC standard (GeoTIFF 1.1), and its cloud-friendly profile — the Cloud Optimized GeoTIFF — is the same format with a smarter internal layout.", "example": "A field office emails a drone survey as a single 2 GB file. The analyst drops it into their GIS and it lands precisely over the existing basemap, correct CRS and all — no calibration, no questions. That it 'just works' is the GeoTIFF tags silently doing their job.", "related": [ "cloud-optimized-geotiff", "raster-data", "georeferencing", "coordinate-reference-system" ], "source": "OGC GeoTIFF 1.1 (OGC 19-008r4)" }, { "slug": "ground-sample-distance", "term": "Ground sample distance", "aka": [ "GSD" ], "category": "imagery", "short": "GSD: the real-world size of one image pixel — 30 cm GSD means each pixel covers 30 cm of ground.", "definition": "Ground sample distance is the distance on the ground between the centers of adjacent pixels — in practice, the real-world width of one pixel. It is the standard precise way to state an image's spatial resolution: '30 cm GSD' means each pixel represents a 30-by-30-centimeter patch of Earth. GSD follows from sensor optics and altitude, so a drone at 100 meters achieves centimeter GSD while a satellite hundreds of kilometers up works in tens of centimeters at best. A useful rule of thumb: reliably recognizing an object takes several pixels across it, so mapping 4-meter huts comfortably wants GSD well under a meter.", "example": "Reviewing an imagery manifest, an engineer sees 'GSD: 0.5 m' and immediately knows what to expect: a 10-meter-wide building will span about 20 pixels — enough to trace its outline confidently — while a 40-centimeter fence post will vanish into a single ambiguous pixel.", "related": [ "spatial-resolution", "aerial-imagery", "satellite-imagery" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "ground-truth", "term": "Ground Truth", "aka": [ "Reference Data", "Answer Key" ], "category": "evaluation", "short": "The trusted answer key a model is scored against — built from surveys and careful mapping, and never quite perfect.", "definition": "Ground truth is the set of answers treated as correct when scoring a model: which pixels really are buildings, which tiles really contain settlements. It comes from field surveys, GPS traces, or careful human mapping of high-resolution imagery. The name is aspirational — real ground truth carries its own errors: mappers miss small structures, imagery is outdated by the time labels are drawn, and boundaries are judgment calls. Good evaluation practice treats ground truth as the best available reference rather than absolute fact, records who made it and when, and remembers that a model 'error' sometimes turns out to be a label error. In OpenStreetMap-based pipelines, map completeness itself varies by place, so the answer key is patchier in exactly the regions that matter most.", "example": "Volunteers carefully trace every rooftop in three Malawian villages from recent drone imagery to build ground truth. Six months later a model is 'wrong' about four buildings — a field visit shows two were built after the drone flight. The answer key aged; the model was right.", "related": [ "training-label", "openstreetmap", "humanitarian-mapping", "precision", "recall" ], "source": "Standard remote-sensing accuracy-assessment practice (Congalton & Green, Assessing the Accuracy of Remotely Sensed Data); qukaizen-geoai/docs/LANDSCAPE.md (OSM as label source, completeness varies by region)" }, { "slug": "hallucination", "term": "Hallucination", "aka": [ "confabulation" ], "category": "models", "short": "A model confidently asserting things that are not there — a building on bare ground; why evidence claims and human review exist.", "definition": "Hallucination is when a model produces confident output unsupported by its input — stating a building exists on bare ground, describing a road the imagery does not show. It is not a rare glitch but a structural tendency: generative models are trained to produce plausible output, and plausible is not the same as true. Constrained generation does not help — it guarantees a well-formed verdict, not a correct one. The defenses in this world's design are procedural: models must attach evidence claims tied to the declared asset so reviewers can check assertions against pixels, every prediction passes human review before export, and nothing flows into OpenStreetMap unreviewed.", "example": "The verdict model returns {\"verdict\":\"yes\",\"score\":0.91} for a tile of rocky scrubland, its evidence citing 'rectilinear roofline with shadow'. The reviewer looks: the 'roofline' is a rock outcrop's shadow edge. One click rejects it — and the win/loss record becomes future training signal.", "related": [ "human-in-the-loop", "review", "model-score", "calibration" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (evidence claims tied to declared assets; human review before export); qukaizen-geoai/docs/LANDSCAPE.md" }, { "slug": "heigit", "term": "HeiGIT", "aka": [ "Heidelberg Institute for Geoinformation Technology" ], "category": "mission", "short": "The Heidelberg research institute behind much of MapSwipe's technology, plus ohsome analytics and openrouteservice.", "definition": "HeiGIT, the Heidelberg Institute for Geoinformation Technology, is a research institute affiliated with Heidelberg University that turns geoinformatics research into working humanitarian tools. It is a core technology partner behind MapSwipe — including the fAIrSwipe workflow that routes AI predictions to volunteers for validation — and builds widely used open services: ohsome, which analyzes OpenStreetMap's full edit history to answer questions about data quality and completeness, and openrouteservice, an OSM-based routing engine with humanitarian instances. HeiGIT represents the research end of the ecosystem: studying how crowdsourced data quality works, not just producing data. It is an independent institution with no QuKaiZen affiliation.", "example": "A researcher wants to know whether a district's OSM building data is complete enough to train a model on. She queries HeiGIT's ohsome API for the area's edit history, sees mapping activity plateaued two years ago after a mapathon campaign, and flags the labels as probably stale for newer construction.", "related": [ "mapswipe", "openstreetmap", "crowdsourcing", "fair" ], "source": "heigit.org; heigit.org/mapswipe; qukaizen-geoai/docs/LANDSCAPE.md (primary references)" }, { "slug": "holdout", "term": "Holdout", "aka": [ "Holdout Set", "Held-out Data" ], "category": "evaluation", "short": "Data locked away until the final exam — and in geography, you hold out whole places, not just rows.", "definition": "A holdout is the portion of data locked away from all training and tuning, touched only for the final evaluation. Its value is exhaustibility: every time you peek at holdout scores and adjust the model in response, the holdout quietly becomes tuning data and its verdict loses meaning. Discipline means deciding the holdout up front, evaluating on it rarely, and reporting what it says even when disappointing. The geographic twist: holding out random rows is not enough, because a held-out tile surrounded by training tiles is barely hidden. Honest geo practice holds out places — entire regions the model has never been near. In qukaizen-geoai's design that decision belongs to the control plane and is recorded by digest, not left to per-run judgment.", "example": "A project reserves two entire districts as its holdout before any training begins. Months of model iterations never touch them. The final run scores 0.77 there — lower than hoped, but it is the one number the team can honestly put in front of MapSwipe partners.", "related": [ "train-test-split", "spatial-split", "spatially-honest-evaluation", "benchmark" ], "source": "Standard machine-learning practice (Hastie, Tibshirani & Friedman, The Elements of Statistical Learning); qukaizen-geoai/CLAUDE.md (splits from control plane, recorded by digest); Roberts et al. 2017 — Cross-validation strategies…, Ecography 40:913-929" }, { "slug": "human-in-the-loop", "term": "Human-in-the-Loop", "aka": [ "HITL" ], "category": "mission", "short": "The structural rule that a human gate sits between every model output and the shared map — designed so it cannot be bypassed.", "definition": "Human-in-the-loop is the ecosystem's structural safety rule: between any model's output and the shared map there is always a human gate, and the systems are designed so the gate cannot be skipped. This is a matter of architecture, not policy. fAIr emits predictions as proposals, not edits; MapSwipe routes them to volunteer judgment; OSM's community norms and automated-edit guidelines prohibit unreviewed bulk uploads; and every edit arrives in a changeset with a human contributor's name on it. The loop exists because models fail confidently in exactly the unfamiliar geographies humanitarian mapping targets, and because a shared map's value rests on contributor accountability. QuKaiZen's geoai design adopts this rule absolutely: no path in its architecture pushes predictions into OSM without human review, by construction.", "example": "A model flags 900 'new buildings' after a storm. Nothing happens to the map. The predictions queue for volunteers, who confirm 740, redraw 60, and reject 100 sun-glare phantoms — and only the human-confirmed features, inside a mapper's own changeset, ever touch OpenStreetMap.", "related": [ "ai-assisted-mapping", "review", "changeset", "crowdsourcing", "hallucination" ], "source": "wiki.openstreetmap.org — Automated Edits code of conduct; qukaizen-geoai/docs/LANDSCAPE.md (what not to do first); docs/COMMUNITY.md" }, { "slug": "humanitarian-mapping", "term": "Humanitarian Mapping", "aka": [ "Crisis Mapping" ], "category": "mission", "short": "Creating map data for vulnerable, unmapped places so aid organizations can find the people who live there.", "definition": "Humanitarian mapping is the practice of putting vulnerable places on the map so that aid can reach the people who live there. Much of the world's population lives in areas that commercial map providers have never prioritized: informal settlements, rural villages, and regions between crises. When an epidemic, flood, or earthquake strikes such a place, responders literally cannot see where the houses and roads are. Volunteers close this gap by tracing buildings and roads from satellite imagery into OpenStreetMap, ideally before disaster strikes rather than during it. The resulting open data supports vaccination campaigns, disaster logistics, census planning, and development work. It is the mission that every tool in this vocabulary ultimately serves.", "example": "During a malaria elimination campaign, health workers need to visit every household in a rural district — but the official map shows blank space. Volunteers worldwide trace thousands of building footprints from satellite imagery in a week, and spray teams then plan routes that reach every roof they mapped.", "related": [ "openstreetmap", "missing-maps", "hot", "mapswipe", "mapper" ], "source": "hotosm.org; missingmaps.org; qukaizen-geoai/docs/LANDSCAPE.md (executive summary)" }, { "slug": "hot", "term": "Humanitarian OpenStreetMap Team", "aka": [ "HOT", "HOTOSM" ], "category": "mission", "short": "The NGO that coordinates OpenStreetMap contributions for disaster response and community development worldwide.", "definition": "The Humanitarian OpenStreetMap Team is the nonprofit that organizes OpenStreetMap's humanitarian work at scale. When a disaster strikes or a health campaign needs maps, HOT activates volunteer mapping efforts, coordinates them through tools like the Tasking Manager, and works with local communities so the data serves people on the ground. HOT also builds and maintains open tooling — the Tasking Manager, fAIr, OpenAerialMap, the Raw Data API — and runs regional hubs supporting local mapping organizations. It is a founding partner of Missing Maps. HOT is an independent NGO; QuKaiZen has no affiliation with it, and any code contribution from the geoai project would follow HOT's own community processes and maintainer agreement.", "example": "Hours after a major earthquake, HOT activates: priority areas appear in the Tasking Manager, thousands of remote volunteers begin tracing collapsed-region imagery, and within days search-and-rescue teams are navigating with maps that did not exist the week before.", "related": [ "openstreetmap", "tasking-manager", "fair", "missing-maps", "humanitarian-mapping" ], "source": "hotosm.org; qukaizen-geoai/docs/LANDSCAPE.md (the strategic relationship); docs/COMMUNITY.md" }, { "slug": "imagery-licensing", "term": "Imagery licensing", "aka": [ "Imagery license", "Imagery terms of use" ], "category": "imagery", "short": "Who may use which pixels for what — and the rule that open derived polygons never open the source imagery.", "definition": "Imagery licensing is the set of legal terms governing what anyone may do with a given set of pixels: view, redistribute, trace features from, train models on. Terms vary enormously — Sentinel-2 and Landsat are free and open; commercial providers restrict redistribution and sometimes derived works; some providers grant OSM-specific tracing waivers. The critical rule this project treats as discipline: openness does not flow backwards. Building polygons released under an open license do not make the imagery they were traced from open, and vice versa. So every experiment records imagery, label, model, and split provenance separately — provider, item identifiers, acquisition time, processing level, and license each named explicitly, never inferred.", "example": "A team finds a great open building dataset and assumes the underlying commercial imagery is fair game for training a model. It is not: the polygons are open, the pixels are not, and shipping model weights trained on them could violate the provider's terms. The manifest's separate provenance fields exist to catch exactly this.", "related": [ "satellite-imagery", "openstreetmap", "provenance-gate", "dac-manifest", "training-label" ], "source": "qukaizen-geoai docs/LANDSCAPE.md — 'Critical licensing rule' (derived-data openness does not extend to source imagery; per-experiment provenance for imagery, labels, model, and splits recorded separately)" }, { "slug": "infer", "term": "Infer", "aka": [ "Inference stage", "geoai run" ], "category": "loop", "short": "The zero-network stage: the model runs inside the secure-zero-egress-claw sandbox on local hardware, and only a result directory comes out.", "definition": "Infer is the stage where the model actually looks at the imagery — and by design it happens with the network physically denied. The verified bundle is dispatched into the secure-zero-egress-claw sandbox profile: no sockets, no DNS, read-only inputs, empty environment, no shell, no subprocesses. Inside, a deterministic worker runs a fixed nine-step pipeline — verify, decode, preprocess, invoke the engine (QueueLLM for reasoning, llama.cpp with GBNF grammars for constrained verdicts in v0), validate outputs against the task schema, write predictions and an execution receipt, exit. Even a hostile instruction hidden in an image cannot phone home, read files, or publish anything. This is the heart of the M1 vertical slice, targeting macOS first; it is design and ROADMAP, not built.", "example": "On a volunteer's MacBook, the Malawi bundle runs for twenty minutes with Wi-Fi still on — but the sandbox denies every socket, so the process could not reach the internet if it tried. It exits leaving predictions.ndjson and a receipt recording that all adversarial egress tests failed as required.", "related": [ "verify-bundle", "review", "secure-zero-egress-claw", "zero-egress", "execution-receipt" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md §3–§4 (sandbox profile, worker pipeline, security invariant); docs/ROADMAP.md M1 items 2–4; read 2026-07-12" }, { "slug": "inference", "term": "Inference", "aka": [ "prediction", "model serving" ], "category": "models", "short": "Running an already-trained model on new data to get predictions — as opposed to training it.", "definition": "Inference is using a trained model: feed it new input, get its output. It is the cheap, read-only half of machine learning — training changes the model's weights, inference just applies them, so the same inputs and weights can yield the same outputs run after run. That property is why qukaizen-geoai's sandbox design permits only inference offline: a worker that merely applies frozen, digest-pinned weights to a pre-fetched bundle needs no network at all, can be locked in a zero-egress sandbox, and can be held to determinism — same bundle, same profile, byte-identical predictions digest, per the design (M0; not yet running code).", "example": "A laptop in a connectivity-poor field office loads a verified bundle — imagery tiles plus pinned model weights — and runs inference over 10,000 tiles overnight with networking disabled. The predictions and their receipt travel back on a USB stick.", "related": [ "infer", "model-weights", "zero-egress", "determinism", "inference-bundle" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (offline execution plane: inference-only worker in the zero-egress sandbox); aerollm/docs/integration-guide.md" }, { "slug": "inference-bundle", "term": "Inference bundle", "aka": [ "Bundle" ], "category": "runtime", "short": "The immutable input package for a run: manifest, task, assets, geometries, model reference, and policy — no URLs, no credentials.", "definition": "The inference bundle is the immutable, fully-resolved package of everything a run needs: a manifest, the task definition with prompt and output schema, imagery assets stored by content hash, vector geometries, a reference to model weights in a shared content-addressed store, and the inference policy. Its defining property is that nothing inside points outward — no URLs, no credentials, no unresolved references; the control plane (qukaizen-dac) fetches and hashes everything before the sandbox ever starts. This makes the bundle the trust boundary: the sandboxed worker verifies the manifest's digests and needs to trust nothing else. The design specifies rejection of bundles containing http(s) inputs, escaping symlinks, undeclared files, or mismatched hashes. Bundle layout and manifest are specified in this repo's v1alpha1 draft schema (M0).", "example": "For a Mozambique road-obstruction run, dac materializes bundle/ containing manifest.json, a task prompt, two GeoTIFFs named by their sha-256 digests, roads.geojson, a model reference, and a policy file. The worker inside the sandbox will never need — and by design will never be able — to fetch anything.", "related": [ "bundle-manifest", "content-addressing", "materialize", "verify-bundle", "sandbox" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§2 'The inference bundle is the trust boundary'); qukaizen-geoai/schemas/geoai.bundle-manifest.v1alpha1.schema.json" }, { "slug": "inference-run", "term": "InferenceRun", "aka": [ "Run declaration" ], "category": "stack", "short": "A run declared as code: dataset, task, model, sandbox profile, and output, each pinned by digest before anything executes.", "definition": "An InferenceRun is the declaration that describes an entire model run before it happens — as a versioned file, not a command someone typed. It names the dataset manifest, the task definition, the model artifact, the sandbox profile, resource limits, and the output schema and directory, and it pins each by an expected digest so the run either executes exactly what was declared or refuses. This makes runs reviewable, diffable, and reproducible the way code is. Status honesty: the YAML shown in geoai's ARCHITECTURE.md is explicitly illustrative; the authoritative schema is dac-side work landing with the unmerged ADR-0005 branch, which geoai consumes as pinned spec per ADR-0001.", "example": "A file named mozambique-road-obstruction-2026-07 declares the dataset (digest sha256:89a4…), the road-obstruction task, the aerollm-moe engine with qwen3-30b-a3b-4bit, the secure-zero-egress-claw profile with a 24 GiB budget and 30-minute timeout, and where validated predictions land.", "related": [ "dac-manifest", "control-plane", "execution-receipt", "determinism", "infer" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md §1 (illustrative InferenceRun YAML); qukaizen-geoai/docs/decisions/0001-repo-boundaries-and-pinned-contracts.md Decision 4" }, { "slug": "intersection-over-union", "term": "Intersection over Union", "aka": [ "IoU", "Jaccard Index" ], "category": "evaluation", "short": "Overlap divided by union of predicted vs true shape — the standard 'did it really outline the building' score.", "definition": "Intersection over union measures how well a predicted shape matches the true one: the area where the two shapes overlap, divided by the total area either covers. A perfect trace scores 1.0; no overlap scores 0. IoU is the standard answer to 'the model found the building, but did it actually outline it?' — a detector can hit the right location while drawing a box twice the building's size, and IoU exposes that. Detection benchmarks in the COCO lineage set an IoU threshold (commonly 0.5) below which a prediction does not count as a true positive at all, so IoU quietly underlies precision and recall for footprint work too.", "example": "A model predicts a rooftop polygon over a clinic. The predicted shape and the hand-traced truth overlap across 72 square meters, and together they cover 90. IoU = 0.80 — good enough to count as a match, though the model clipped one wing of the building.", "related": [ "building-footprint", "semantic-segmentation", "object-detection", "precision", "ground-truth" ], "source": "COCO detection evaluation (cocodataset.org); Jaccard index (Jaccard 1901, standard attribution)" }, { "slug": "knowledge-world", "term": "Knowledge World", "aka": [ "World" ], "category": "stack", "short": "A sourced, connected, gate-passed little universe of knowledge — like the one you are reading right now.", "definition": "A Knowledge World is a small universe of knowledge built to three rules: every fact is sourced, everything connects, and gaps are declared rather than hidden. Concretely it is five files: a spec (name, categories, trusted sources), a roster (what should exist, including honest gaps), verified card shards (each fact with a gist, explanation, vivid example, and source), a generated terms.json that is the compiled truth, and an optional README. An assembler script runs the provenance gate over the shards; green means a real World. The engine and gate are BUILT — this geoai World is compiled by them. The deeper point is pedagogical: finding the sources and drawing the connections is the education. Humans learn, machines do.", "example": "The worked example is art-history: 103 cards on an 8-era spine from Greek vases to Pop Art, where each painting card threads to its era and its cousins in music and film. This geoai World follows the same recipe with satellite imagery instead of brushstrokes.", "related": [ "docent", "provenance-gate", "data-as-code", "arail" ], "source": "qukaizen-dac/data/worlds/README.md (the five files, the 7-step recipe, the three rules)" }, { "slug": "landsat", "term": "Landsat", "aka": [ "Landsat program" ], "category": "imagery", "short": "The NASA/USGS program imaging Earth since 1972 — the free-and-open archive that changed the field.", "definition": "Landsat is the joint NASA/USGS satellite program that has imaged Earth's land surface continuously since 1972 — the longest-running earth-observation record in existence. Current satellites (Landsat 8 and 9) collect multispectral imagery at 30-meter resolution, with each satellite revisiting a given spot every 16 days. The program's largest legacy is a policy decision: in 2008 the USGS made the entire archive free and open, which transformed remote sensing from a budget line into a commodity and set the precedent Copernicus later followed. Fifty-plus years of comparable imagery make Landsat the reference for long-term change — deforestation, urbanization, glacier retreat, coastline shift — even where its resolution is too coarse for building-level mapping.", "example": "To show a community how their watershed changed, an educator pulls Landsat scenes of the same valley from 1985, 2005, and 2025 — same program, comparable bands. The reservoir appears, the forest edge retreats, the town triples. No other archive on Earth can replay four decades like that.", "related": [ "earth-observation", "sentinel-2", "multispectral", "spatial-resolution" ], "source": "NASA Landsat science (landsat.gsfc.nasa.gov)" }, { "slug": "layer-streaming", "term": "Layer streaming", "aka": [ "Weight streaming", "Disk-resident inference" ], "category": "stack", "short": "QueueLLM's core trick: model weights live on NVMe and flow through RAM piece by piece, so models bigger than memory still run.", "definition": "Layer streaming is how a model larger than your computer's memory can still run on it. Instead of loading every weight up front, QueueLLM keeps the model on fast NVMe storage and streams the pieces it needs through RAM as computation proceeds — layer by layer for dense models, expert by expert for Mixture-of-Experts models, where only a few experts activate per token. The engine reads what the model is and picks the matching streaming policy, backed by a bounded shard cache, double-buffered prefetch from disk, and ring eviction. The trade is speed for feasibility: huge models become batch workloads rather than chat partners, while MoE models with small active-parameter counts stay genuinely usable. This is BUILT, with measured numbers published in aerollm's README.", "example": "Think of a chef with a tiny counter and a huge pantry: instead of hauling every ingredient out at once, they fetch each item just before it is needed and return it after. The counter (RAM) stays small; the recipe (a 215 GB model) still gets cooked.", "related": [ "aerollm", "model-weights", "quantization", "inference" ], "source": "aerollm/README.md (architecture-aware streaming, status primitives: mmap shard cache, double-buffered NVMe prefetch, ring eviction)" }, { "slug": "llama-cpp", "term": "llama.cpp", "aka": [ "llama-cpp", "GGML" ], "category": "models", "short": "The open-source C/C++ inference engine that runs quantized LLMs on ordinary hardware; geoai v0's constrained-verdict engine.", "definition": "llama.cpp is the widely used open-source (MIT) C/C++ engine for running large language models locally, built on the GGML tensor library. It popularized aggressive quantization via the GGUF file format, making multi-billion-parameter models practical on laptops, and it ships mature GBNF grammar enforcement for constrained generation. In qukaizen-geoai's v0 design it plays a specific role: the constrained verdict engine — a small quantized model plus a per-World grammar producing schema-exact verdicts — running beside aerollm, which handles long-form reasoning. The split exists because aerollm does not yet implement grammar-level constraints; it is a design decision (established in dac ADR-0005), with the grammar mechanism itself proven in a 2026-07-11 hardware spike.", "example": "In the designed worker, each tile observation is dispatched twice: llama.cpp with the verdict grammar returns the machine-parseable classification, while aerollm writes the free-text evidence narrative a reviewer will actually read. Both outputs land in the same prediction record.", "related": [ "gbnf", "aerollm", "quantization", "constrained-generation", "geoai-runtime" ], "source": "llama.cpp repository and grammars/README.md (github.com/ggml-org/llama.cpp); qukaizen-geoai/docs/ARCHITECTURE.md (v0 engine split per dac ADR-0005)" }, { "slug": "map-tile", "term": "Map tile", "aka": [ "Slippy map tile", "XYZ tile" ], "category": "imagery", "short": "The slippy-map trick: the world pre-cut into 256-pixel squares, each addressed by z/x/y.", "definition": "A map tile is one small square piece of a map — conventionally 256 by 256 pixels — from a scheme that pre-cuts the entire world into a pyramid of such squares. Each tile has an address of three integers: z (zoom level), x (column), y (row), so a browser showing any view just fetches the handful of tiles covering it, and panning 'slips' new tiles in at the edges — hence 'slippy map.' The scheme, popularized by OpenStreetMap and built on Web Mercator, works identically for rendered street maps and satellite imagery, and the same z/x/y grid is how tasks are carved up for volunteers in tools like MapSwipe.", "example": "A MapSwipe volunteer swipes through what feel like snapshots of countryside, tapping any square containing buildings. Each square is literally a map tile — an addressed z/x/y cell of imagery — so every tap attaches a human judgment to exact, machine-readable coordinates that a model pipeline can consume directly.", "related": [ "zoom-level", "web-mercator", "basemap", "mapswipe" ], "source": "wiki.openstreetmap.org — Slippy map tilenames / Zoom levels" }, { "slug": "mapathon", "term": "Mapathon", "aka": [ "Mapping Party" ], "category": "mission", "short": "A mapping party: a room (or video call) full of volunteers tracing buildings and roads together for a humanitarian project.", "definition": "A mapathon is a mapping party — an organized event where a group of volunteers, often complete beginners, spend a few hours tracing buildings and roads from satellite imagery for a humanitarian project. A typical mapathon opens with a short training on the editing tools, assigns everyone tasks from a Tasking Manager project, and mixes newcomers with experienced mappers who answer questions and validate work. Universities, companies, and community groups host them; since 2020 many run remotely over video call. Mapathons matter beyond the map data produced: they are the main recruitment funnel for the humanitarian mapping community, turning curious first-timers into regular contributors — and sometimes, eventually, into validators.", "example": "Forty students gather in a university lab on a Thursday evening. After a twenty-minute intro to the iD editor, they load a Tasking Manager project for a flood-prone district in South Sudan. By the time the pizza runs out, they have traced four thousand buildings, each square checked by an experienced validator at the back of the room.", "related": [ "missing-maps", "tasking-manager", "mapper", "youthmappers", "crowdsourcing" ], "source": "missingmaps.org — events; hotosm.org; wiki.openstreetmap.org — Mapathon" }, { "slug": "maplibre", "term": "MapLibre", "aka": [ "MapLibre GL JS" ], "category": "stack", "short": "The open-source map rendering library (a community fork of Mapbox GL, BSD-licensed) the review UI is designed on.", "definition": "MapLibre is the open-source library that draws interactive maps in a web browser — smooth panning, zooming, and layering of imagery tiles and vector overlays, all rendered on the GPU. It began as a community fork of Mapbox GL JS in 2020, after Mapbox moved its library to a proprietary license, and continues under a permissive BSD license with open governance. For qukaizen-geoai it is the designed foundation of the review UI: a localhost MapLibre page is the smallest cross-platform way to show satellite imagery, prediction geometries, and evidence regions together without shipping a desktop app. Status honesty: MapLibre itself is mature, widely used open source; the geoai review UI built on it is ROADMAP.", "example": "In the designed review flow, MapLibre renders the basemap and imagery tiles, draws each predicted building footprint as a vector overlay, and lets the analyst zoom from country level to a single rooftop — the same interaction pattern OSM mappers already know from web editors.", "related": [ "review-ui", "map-tile", "basemap", "vector-data", "web-mercator" ], "source": "maplibre.org (project history and BSD licensing); qukaizen-geoai/docs/ARCHITECTURE.md (Human interface: localhost MapLibre interface)" }, { "slug": "mapper", "term": "Mapper", "aka": [ "Contributor", "Validator" ], "category": "mission", "short": "The human at the center of it all: traces features, validates others' work, and grows from beginner to trusted validator.", "definition": "A mapper is the human at the center of the whole ecosystem: the person who traces buildings and roads from imagery, surveys places on the ground, reviews other people's edits, and judges AI predictions. Mapping skill is a real progression. Beginners start at mapathons tracing simple buildings; with practice they learn imagery interpretation — telling roofs from shadows, spotting offset imagery — and take on harder feature types; experienced mappers become validators, the trusted reviewers who check completed work in the Tasking Manager and mentor newcomers through changeset comments. Every quality mechanism in the ecosystem — crowd agreement, validation, human review of AI output — ultimately resolves to a mapper's judgment. Tools like fAIr and MapSwipe exist to make that judgment faster and better placed, never to replace it.", "example": "Ana traced her first wobbly building at a campus mapathon two years ago. Now she validates other people's task squares, recognizes when imagery is offset before trusting it, and spends her MapSwipe commute time judging AI-proposed footprints — accepting the clean ones, rejecting the ones hugging shadows.", "related": [ "validate", "changeset", "tasking-manager", "mapathon", "ai-assisted-mapping" ], "source": "wiki.openstreetmap.org — Beginners' guide; missingmaps.org; tasks.hotosm.org — validation" }, { "slug": "mapswipe", "term": "MapSwipe", "category": "mission", "short": "The volunteer app where anyone can help mapping by swiping through imagery tiles and tapping yes, no, or maybe.", "definition": "MapSwipe is a volunteer app that turns map contribution into something anyone can do on a phone: look at a small square of satellite imagery, tap to say whether it contains buildings (or roads, or changes), and swipe to the next one. Born out of the Missing Maps project with partners including the Heidelberg Institute for Geoinformation Technology (HeiGIT), it has recorded over 215 million swipes from more than 132,000 contributors. Its project types now include finding features, comparing before/after imagery, validating building footprints, checking OSM completeness, and assessing individual images — several of which directly quality-check AI predictions. MapSwipe is an independent community project; QuKaiZen is not affiliated with it and hopes to serve it.", "example": "Waiting for a bus, a first-time volunteer opens MapSwipe, picks a malaria-campaign project in Mozambique, and swipes through imagery tiles tapping wherever she spots a roof. Ten minutes later she has classified two hundred tiles, and her taps will be combined with other volunteers' to steer expert mappers to the right places.", "related": [ "missing-maps", "heigit", "crowdsourcing", "fair", "human-in-the-loop" ], "source": "mapswipe.org; heigit.org/mapswipe; qukaizen-geoai/docs/LANDSCAPE.md (MapSwipe is the human judgment layer)" }, { "slug": "materialize", "term": "Materialize", "aka": [ "dac materialize" ], "category": "loop", "short": "dac materialize resolves every reference into an immutable, content-addressed inference bundle — no URLs or credentials survive into it.", "definition": "Materialize is the packing stage: everything a model run will need is gathered into one sealed box before anything executes. The designed command, `dac materialize project.yaml`, resolves every declared reference — imagery, geometries, task definition, prompt, output schema, a model reference into a shared content-addressed store — into a single immutable bundle in which every file is named and pinned by its sha-256 digest. Critically, nothing unresolved survives: no URLs, no credentials, no absolute host paths. This is what makes the later offline stages possible — a bundle that needs nothing from the network can be run with the network denied. The bundle format is this repo's `geoai.bundle-manifest/v1alpha1` schema (draft; runtime is ROADMAP, first built in the M1 slice).", "example": "The operator runs dac materialize on the Malawi project file. DaC copies the three hashed GeoTIFFs into assets/, writes the road-obstruction task and its JSON output schema into task/, drops a digest-pinned model reference into model/, and emits manifest.json listing every file by hash. The result could be burned to a USB stick and run on an air-gapped laptop.", "related": [ "acquire", "verify-bundle", "inference-bundle", "content-addressing", "data-as-code" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md §2 (\"The inference bundle is the trust boundary\") and \"Developer CLI\"; schemas/geoai.bundle-manifest.v1alpha1.schema.json; read 2026-07-12" }, { "slug": "metadata-endpoint", "term": "Metadata endpoint", "aka": [ "Cloud metadata service", "169.254.169.254" ], "category": "runtime", "short": "The cloud trap: a link-local server (169.254.169.254) that hands out credentials to any process on the machine that asks.", "definition": "The metadata endpoint is a service cloud providers run at the link-local address 169.254.169.254, reachable from inside any virtual machine without any real networking — no DNS, no internet route required. It answers with the machine's identity, configuration, and, critically, temporary cloud credentials. That makes it a classic exfiltration and privilege-escalation trap: code that appears fully offline can still reach this address and walk away with keys to the hosting account, a pattern behind several famous real-world breaches. Because 'no internet' does not imply 'no metadata endpoint', qukaizen-geoai's egress test suite is designed to probe this address explicitly from inside the sandbox and require the attempt to fail, rather than assuming that denying DNS and public routes was enough.", "example": "A container runs with outbound internet blocked and its operator believes it is isolated. A malicious dependency issues one HTTP GET to http://169.254.169.254/latest/meta-data/iam/ and receives working cloud credentials — no DNS lookup, no external packet. The suite's dedicated probe exists to prove that this exact move is impossible here.", "related": [ "egress-test-suite", "egress", "zero-egress", "sandbox" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§3 egress test enumeration, cloud metadata IPs); AWS EC2 Instance Metadata Service documentation (standard external attribution)" }, { "slug": "missing-maps", "term": "Missing Maps", "category": "mission", "short": "The coalition — HOT, MSF, Red Cross and others — that maps vulnerable places before crises hit, not after.", "definition": "Missing Maps is a coalition of humanitarian organizations — founded in 2014 by the Humanitarian OpenStreetMap Team, Médecins Sans Frontières, and the American and British Red Cross — built around one insight: the most vulnerable places should be mapped before disaster strikes, not scrambled onto the map mid-crisis. The project mobilizes volunteers through mapathons and apps (MapSwipe grew out of Missing Maps), remote mappers trace base features from imagery, local volunteers add names and detail on the ground, and humanitarian organizations use the resulting OpenStreetMap data to plan their work. It is an open collaboration that any organization or individual can join; QuKaiZen is not a member and simply hopes its tools may one day be useful to this mission.", "example": "An MSF epidemiologist knows cholera outbreaks recur in a lakeside region no one has mapped. Through Missing Maps, volunteers trace every village months before the rainy season — so when cases appear, response teams already know where each settlement is and how to reach it.", "related": [ "hot", "mapswipe", "mapathon", "humanitarian-mapping", "remote-mapping" ], "source": "missingmaps.org; mapswipe.org — about; qukaizen-geoai/docs/LANDSCAPE.md" }, { "slug": "model-score", "term": "Model Score", "aka": [ "confidence score", "raw score" ], "category": "models", "short": "The raw number a model emits alongside a prediction — useful for ranking, but NOT a calibrated probability.", "definition": "A model score is the number a model attaches to each prediction — 0.91 for this footprint, 0.42 for that one. It is tempting to read it as a probability ('91% chance this is a building'), and that reading is usually wrong: raw scores from neural networks are systematically miscalibrated, often overconfident, and not comparable across models, quantizations, or regions. Scores are still useful relatively — for ranking predictions and routing the low end to human review first. qukaizen-geoai's prediction schema deliberately carries the raw score only, refusing to launder it into a pseudo-probability; if calibration is ever applied, that is a separate, evaluated, recorded step.", "example": "Two runs over the same district: the fp16 model scores a tin-roofed house 0.88, its int4 quantization scores it 0.79. Neither number is 'the probability it is a building' — but within each run, sorting by score still puts the dubious rock-shadow detections at the reviewer's front of queue.", "related": [ "calibration", "prediction-record", "review", "quantization" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (prediction carries the raw model score only); qukaizen-geoai/schemas (prediction v1alpha1 draft)" }, { "slug": "model-weights", "term": "Model Weights", "aka": [ "weights", "parameters", "checkpoint" ], "category": "models", "short": "The learned numbers that ARE the model — billions of values set by training, shipped as files.", "definition": "Model weights are the numbers a neural network learned during training — millions to billions of values that, together with the architecture code, are the model. Ship someone the weights file and they can run the model; change one weight and it is a different model. That file-ness is what makes weights governable: they can be hashed, pinned by digest, versioned, and license-checked like any artifact. In qukaizen-geoai's design, weights arrive inside a content-addressed inference bundle, verified by SHA-256 before the worker will load them, and the execution receipt records exactly which weights digest produced which predictions — a design commitment, with M1 as the first build.", "example": "Two field teams report different predictions for the same tiles. The receipts settle it in seconds: one team's bundle carried weights digest sha256:9f3a…, the other sha256:c41b… — a stale bundle, not a nondeterminism bug.", "related": [ "quantization", "content-addressing", "sha-256", "bundle-manifest", "inference" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (digest-pinned model artifacts in the bundle manifest); aerollm/docs/integration-guide.md" }, { "slug": "multispectral", "term": "Multispectral", "aka": [ "Multispectral imagery" ], "category": "imagery", "short": "Imagery recording several spectral bands per scene — typically 4 to 13 — not just red, green, blue.", "definition": "Multispectral imagery records the same scene in several separate spectral bands — typically somewhere between four and around a dozen — rather than only the red, green, and blue a normal camera captures. Sentinel-2, for instance, records 13 bands from visible through shortwave infrared. What that buys over RGB is discrimination: materials that look identical to the eye have different signatures across the extra bands, so multispectral data can separate crop types, detect moisture, flag burned ground, and feed indices like NDVI. For machine learning, each band is another input channel. The cost is bulkier files and the need to choose which bands a given analysis actually consumes.", "example": "Asked to map flood extent under partial haze, an analyst gives up on natural color and builds a false-color composite from shortwave-infrared, NIR, and red bands. Floodwater snaps into deep blue against bright vegetation — a boundary that simply is not visible in the RGB version of the same scene.", "related": [ "spectral-band", "near-infrared", "ndvi", "sentinel-2", "raster-data" ], "source": "ESA Sentinel Online — Copernicus Sentinel-2 documentation; Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "ndvi", "term": "NDVI", "aka": [ "Normalized Difference Vegetation Index" ], "category": "imagery", "short": "The classic vegetation index: (NIR − Red) / (NIR + Red), yielding −1 to +1, greener is higher.", "definition": "NDVI, the Normalized Difference Vegetation Index, is a simple formula that turns two spectral bands into a single number describing how much healthy vegetation a pixel contains: (NIR − Red) / (NIR + Red). It exploits a physical contrast — healthy plants reflect near-infrared strongly and absorb red light for photosynthesis — so lush vegetation scores high (0.6 and above), bare soil sits near 0.2, and water goes negative. The normalization keeps values comparable across scenes and lighting. Computed per pixel over an image, NDVI produces a vegetation map; computed over time, it tracks crop cycles, drought stress, and deforestation. It is the canonical example of squeezing meaning out of bands.", "example": "A food-security analyst computes NDVI over the same district every ten days through the growing season. In a normal year the curve climbs to 0.7 by mid-season; this year it stalls at 0.35 across three provinces — a quantitative early warning of crop failure, months before harvest data exists.", "related": [ "near-infrared", "spectral-band", "multispectral", "raster-data" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed.; NASA Landsat science (landsat.gsfc.nasa.gov)" }, { "slug": "near-infrared", "term": "Near-infrared", "aka": [ "NIR" ], "category": "imagery", "short": "NIR: the invisible band just beyond red light, where healthy vegetation reflects brilliantly.", "definition": "Near-infrared is the part of the spectrum just beyond visible red light — wavelengths roughly 0.7 to 1.4 micrometers — invisible to human eyes but routinely recorded by satellite sensors. Its signature property: the internal structure of healthy plant leaves scatters near-infrared strongly, so living vegetation appears extremely bright in this band, while water absorbs it almost entirely and appears nearly black. That sharp contrast makes NIR the workhorse band for mapping vegetation health, irrigation, and flooding. It is one half of the NDVI formula, and its presence is a big part of what makes multispectral imagery more informative than a plain photograph.", "example": "During a slow-onset drought assessment, an analyst flips a Sentinel-2 scene from natural color to the NIR band. Riverbank farmland that looked uniformly khaki splits instantly into bright, still-irrigated plots and dark, failed ones — a triage map for where food aid will be needed first.", "related": [ "spectral-band", "ndvi", "multispectral", "sentinel-2" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "nucleus", "term": "Nucleus", "aka": [ "Project Nucleus", "qukaizen-nucleus" ], "category": "stack", "short": "The bake pipeline: distills a big teacher model plus a gate-passed World into a small, owned, sealed specialist model.", "definition": "Nucleus is QuKaiZen's model-building pipeline: it takes reasoning from large teacher models (70B–350B) and distills it into small specialist models (1–7B) you own outright — the metric is 'Wisdom per Watt.' Its pipeline runs curation into distillation into an adversarial swarm that attacks the student until scores converge, then certification and a sealed, versioned release with a reproducible corpus behind it. For GeoAI, Nucleus is the target state, not the present: the plan is to bake a geo-specialist small MoE vision-language model from reviewed (observation, verdict, human win/loss/tie) tuples once enough reviewed data exists. That bake is ROADMAP — until then the GeoAI design names off-the-shelf models, per ARCHITECTURE.md.", "example": "Every time a human reviewer marks a building-detection verdict as win, loss, or tie in the future review UI, that judgment is destined for a bake corpus. Enough of them, and Nucleus distills a small model that has internalized what reviewers kept correcting.", "related": [ "specialist-model", "fine-tuning", "aerollm", "knowledge-world", "human-in-the-loop" ], "source": "qukaizen-nucleus/TECH_BRIEF.md; qukaizen-geoai/docs/ARCHITECTURE.md repo-ownership table (specialist model building: ROADMAP)" }, { "slug": "object-detection", "term": "Object Detection", "aka": [ "detection" ], "category": "models", "short": "Finding individual things in an image and drawing a box around each one, with a class and a score.", "definition": "Object detection finds each distinct thing in an image and outputs a bounding box, a class label, and a score for it. Where semantic segmentation answers 'which pixels are building?', detection answers 'how many buildings, and where is each one?' — it separates instances. Detectors like the YOLO and Faster R-CNN families trade precision of outline for that instance awareness, so mapping pipelines often combine approaches: a detector proposes objects, then a segmentation or mask model refines each boundary. Promptable models like Segment Anything invert this — given a detector's box as a prompt, they return a tight mask, useful for footprint refinement.", "example": "A detector run over drone imagery of a refugee settlement returns 214 boxes labeled 'shelter', each with a score. Those boxes become prompts for SAM-style boundary refinement, and the count itself is already useful for camp population estimates before any polygon is drawn.", "related": [ "semantic-segmentation", "building-footprint", "model-score", "aerial-imagery" ], "source": "arXiv:2304.02643 — Segment Anything; qukaizen-geoai/docs/LANDSCAPE.md (SAM 2.1 as refinement, not replacement detector)" }, { "slug": "openstreetmap", "term": "OpenStreetMap", "aka": [ "OSM" ], "category": "mission", "short": "The free, editable map of the world — a wiki of geography, built by millions of contributors under the ODbL license.", "definition": "OpenStreetMap is the wiki of maps: a free, editable map of the whole world that anyone can contribute to and anyone can use. Founded in 2004, it is maintained by millions of registered contributors who trace features from imagery, survey places in person, and import compatible open datasets. The data — buildings, roads, waterways, place names, and much more — is published under the Open Database License (ODbL), which keeps it open forever. OSM is where reviewed humanitarian mapping work ultimately lands and lives. It is also geographically uneven: rich in well-resourced cities, sparse in exactly the places humanitarian mapping targets, which is why it should never be assumed to be complete ground truth.", "example": "A Red Cross logistics planner in a flood response opens a map of the affected delta. Every road and building she sees was contributed by volunteers — some tracing from their sofas in other countries, some locals naming the streets they walk daily — all merged into one shared database anyone can download.", "related": [ "changeset", "mapper", "hot", "humanitarian-mapping", "ground-truth" ], "source": "openstreetmap.org/copyright; wiki.openstreetmap.org; qukaizen-geoai/docs/LANDSCAPE.md (public data landscape)" }, { "slug": "orthorectification", "term": "Orthorectification", "aka": [ "Ortho correction", "Orthophoto generation" ], "category": "imagery", "short": "Correcting imagery for terrain relief and camera tilt so it has uniform scale and measures like a map.", "definition": "Orthorectification is the processing step that turns a raw aerial or satellite image into something with the geometry of a map. Raw images are distorted: the camera views the ground at an angle, hills lean away from the sensor, tall features displace outward from the image center, and scale varies across the frame. Orthorectification uses an elevation model and the sensor's position to remove these effects, producing an orthophoto in which every pixel sits at its true map position and distances measure correctly everywhere. Without it, features traced from imagery would land meters from their real locations — so orthorectified imagery is the assumed baseline for tracing into OpenStreetMap.", "example": "A mapper traces a mountain clinic from raw drone imagery, then visits with GPS and finds the building 15 meters from where they drew it. The hillside had leaned in the un-corrected image. After orthorectification against an elevation model, the traced outline and the GPS points coincide.", "related": [ "georeferencing", "aerial-imagery", "basemap", "remote-mapping" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "precision", "term": "Precision", "aka": [ "Positive Predictive Value" ], "category": "evaluation", "short": "Of everything the model flagged, how much was real — the false-alarm meter.", "definition": "Precision answers: when the model says 'building here,' how often is it right? It is the count of true positives divided by everything the model flagged (true positives plus false positives). High precision means few false alarms; low precision means reviewers wade through junk. Precision says nothing about what the model missed — a model that timidly flags only the ten most obvious buildings in a city can score perfect precision while ignoring thousands. That is why precision is always read alongside recall, its complement. In human-review pipelines, precision translates directly into volunteer time: every false positive is a prediction someone must look at and reject.", "example": "A model flags 200 building footprints across a village's tiles; reviewers confirm 160 are real buildings and 40 are rock outcrops and vehicle shadows. Precision is 160/200 = 0.80 — one in five flags wasted a volunteer's click.", "related": [ "recall", "f1-score", "confusion-matrix", "review", "human-in-the-loop" ], "source": "Standard information-retrieval and detection metrics (van Rijsbergen, Information Retrieval, 1979); COCO detection evaluation (cocodataset.org)" }, { "slug": "prediction-record", "term": "Prediction record", "aka": [ "geoai.prediction/v1alpha1" ], "category": "runtime", "short": "One model judgment: a label, evidence claims anchored to geometry, alternative explanations, and the raw model score only.", "definition": "A prediction record captures one model judgment about one item, in a shape built for honest human review. The geoai.prediction/v1alpha1 schema (a shipped draft; the emitting worker is M1) contains: the item and task identity; an observation with a label, evidence claims each pairing a plain-language statement with GeoJSON geometry anchored to a declared asset, and alternative explanations the model itself offers; and a scores block carrying the raw model score plus a 'constrained' flag stating truthfully whether grammar-constrained generation was applied. Deliberately absent: any calibrated or operational confidence — the sandboxed run must not invent certainty. Calibration, abstention, and review state are added later by the control plane. Records are specified to be written one per line into predictions.ndjson inside the immutable result directory.", "example": "The worked example reads: label 'possible_obstruction', evidence claim 'water-like region overlaps the declared road corridor' with a polygon over Mozambican coordinates and the source asset's digest, alternatives 'seasonal water' and 'image-registration mismatch', raw score 0.83. A reviewer sees the claim, the place, and the doubt — together.", "related": [ "execution-receipt", "geojson", "model-score", "review", "human-in-the-loop" ], "source": "qukaizen-geoai/schemas/geoai.prediction.v1alpha1.schema.json; qukaizen-geoai/schemas/examples/prediction.example.json; qukaizen-geoai/docs/ARCHITECTURE.md ('Result contract')" }, { "slug": "provenance-gate", "term": "Provenance gate", "aka": [ "The Librarian", "The gate" ], "category": "stack", "short": "The strict librarian of DaC: no card without a source, no thread to a missing card, no undeclared category — green gate means a real World.", "definition": "The provenance gate is the automated check that turns a pile of card files into a trustworthy Knowledge World. Run by the assembler script, it refuses to shelve any card without a source, refuses any related-edge pointing at a card that does not exist, and refuses any category the spec did not declare. Its stderr output is the author's worklist; only a green gate produces the compiled terms.json. The gate is BUILT and runs on every World assembly, including this one. It is also the lesson wearing a uniform: cite your sources, connect your ideas, be honest about what you have not covered — enforced by machine instead of trusted to discipline. The same gate idea appears dac-wide, where dataset assets are refused without license and digest records.", "example": "An author writes a beautiful card but forgets the source field, and links it to 'autoresearch' — a term not in the roster. The gate rejects both: the card stays off the shelf and the dangling thread is reported, not silently dropped into a broken graph.", "related": [ "knowledge-world", "data-as-code", "docent", "imagery-licensing" ], "source": "qukaizen-dac/data/worlds/README.md (step 7, the Librarian; scripts/assemble-world.mts)" }, { "slug": "quantization", "term": "Quantization", "aka": [ "int4", "GGUF quantization" ], "category": "models", "short": "Shrinking model weights to lower-precision numbers so big models fit consumer hardware, at small accuracy cost.", "definition": "Quantization stores a model's weights in fewer bits per number — from 16-bit floats down to 8-, 5-, or 4-bit integers — shrinking the file and the memory needed to run it by 2–4x or more. The trade is a small accuracy loss, usually tolerable, occasionally not, which is why quantized models should be re-evaluated rather than assumed equivalent. It is the enabling trick for the whole local-inference world: a 4-bit quantized model in llama.cpp's GGUF format runs on a laptop that could never hold the fp16 original. Note that quantized weights are different artifacts with different digests — a receipt pins exactly which quantization ran.", "example": "The field laptop has 16 GB of RAM. The fp16 verdict model would need roughly 14 GB by itself; its int4 GGUF quantization needs under 5, leaving room for imagery tiles — and the bundle manifest pins the quantized file's digest, not the original's.", "related": [ "model-weights", "llama-cpp", "aerollm", "inference" ], "source": "llama.cpp quantization documentation (github.com/ggml-org/llama.cpp); aerollm/docs/integration-guide.md" }, { "slug": "aerollm", "term": "QueueLLM", "aka": [ "QueueLLM" ], "category": "stack", "short": "QuKaiZen's open-source inference engine: runs big LLMs on ordinary machines by streaming weights from NVMe instead of RAM.", "definition": "QueueLLM is the open-source engine (Apache-2.0, BUILT and shipping) that runs large language models on machines that could never hold them fully in memory. Its trick is architecture-aware streaming: weights live on fast NVMe disk and stream through RAM as needed, with policies matched to whether the model is dense, Mixture-of-Experts, or hybrid. It ships as a Rust workspace with a CLI plus an aerollm_api Python wheel for embedding. In the GeoAI design it is the long-form reasoning engine inside the sandbox. Two honest gaps shape v0: it has no vision input yet (ADR 0020, Proposed, in progress on a branch) and no constrained generation — which is why the design pairs it with llama.cpp for grammar-enforced verdicts.", "example": "A 405B-parameter model, 215 GB on disk, runs on a 36 GB MacBook at 0.004 tokens per second — an overnight-batch capability proof, not a chat experience. Meanwhile Qwen3-30B-A3B chats at ~31 tok/s on a 24 GB Mac: the commodity-hardware headline.", "related": [ "layer-streaming", "llama-cpp", "execution-plane", "quantization", "model-weights" ], "source": "aerollm/README.md (proof points, honest-scope notes); aerollm/docs/integration-guide.md; qukaizen-geoai/docs/ARCHITECTURE.md model-configuration table" }, { "slug": "qukaizen", "term": "QuKaiZen", "category": "stack", "short": "The umbrella: a family of products built on the idea that useful AI should be owned, sourced, and run on your own machine.", "definition": "QuKaiZen is the family name over everything in this world's stack. The shared conviction: AI capability you rely on should be owned (weights on your disk, not an API subscription), sourced (every fact and dataset carries provenance), and locally run (inference on your own hardware, offline when it matters). Five products divide the work: Data as Code declares knowledge and datasets as gated, versioned code; QueueLLM runs large models on modest machines; Nucleus bakes owned specialist models; ARAIL is the shareable lab where friends and family explore; and qukaizen-geoai applies the whole stack to humanitarian mapping. Each repo keeps a single responsibility, with contracts pinned across boundaries rather than code shared.", "example": "A recruit asks 'which repo do I look in?' The answer is a routing question: dataset manifests and this very vocabulary live in DaC, the engine that runs the model is QueueLLM, the model-baking pipeline is Nucleus, the lab UI is ARAIL, and the zero-egress mapping runtime design is qukaizen-geoai.", "related": [ "data-as-code", "aerollm", "nucleus", "arail", "geoai-runtime" ], "source": "qukaizen-geoai/CLAUDE.md; ProJects/CLAUDE.md workspace overview; qukaizen-geoai/docs/decisions/0001-repo-boundaries-and-pinned-contracts.md" }, { "slug": "geoai-runtime", "term": "qukaizen-geoai", "aka": [ "GeoAI runtime", "the geoai repo" ], "category": "stack", "short": "The product this world orbits: a zero-egress inference runtime, review UI, and evaluation kit for the MapSwipe/fAIr ecosystem.", "definition": "qukaizen-geoai is the humanitarian GeoAI product this whole vocabulary exists to serve: a zero-egress inference runtime plus a human review interface plus an evaluation kit, aimed at the MapSwipe and HOT-fAIr mapping communities. It owns the offline execution plane (bundle verification, the secure-zero-egress-claw sandbox profile, a deterministic worker embedding QueueLLM, execution receipts) and the review plane (a localhost MapLibre UI, MapSwipe/fAIr export adapters, spatially honest evaluation). Status honesty, stated plainly: the repo is at M0 — the architecture docs and v1alpha1 schema drafts are shipped, and everything executable is ROADMAP. A hard product rule regardless of milestone: nothing it produces reaches OpenStreetMap without human review.", "example": "The end-state picture: a MapSwipe-style triage task runs on an analyst's laptop with the network provably dead, predictions appear beside imagery evidence in a local map UI, a human approves or corrects each one, and only then does an export package leave the machine.", "related": [ "execution-plane", "review-ui", "mapswipe", "fair", "spatially-honest-evaluation" ], "source": "qukaizen-geoai/CLAUDE.md (one-paragraph definition, M0 state); qukaizen-geoai/docs/ARCHITECTURE.md; qukaizen-geoai/docs/decisions/0001-repo-boundaries-and-pinned-contracts.md Decision 1" }, { "slug": "raster-data", "term": "Raster data", "aka": [ "Gridded data" ], "category": "imagery", "short": "The grid-of-pixels data model: space divided into equal cells, each holding measured values.", "definition": "Raster data represents the world as a regular grid of cells — pixels — each storing one or more numeric values for the patch of ground it covers. Satellite images, elevation models, NDVI layers, and rainfall grids are all rasters; a multispectral scene is simply a raster with several values per cell, one per band. The model's strengths are continuous phenomena and anything a sensor measures: every location gets a value, and per-pixel math (like computing NDVI) is trivial. Its weaknesses are file size, resolution limits, and clumsiness at representing discrete objects — a building in a raster is just a blob of pixels until something extracts it as vector geometry.", "example": "A segmentation model consumes a raster (the image) and produces another raster: a grid where each pixel holds the probability it belongs to a building. Only a vectorization step turns those probability blobs into crisp polygons a human can review — the moment the data crosses from raster to vector.", "related": [ "vector-data", "geotiff", "satellite-imagery", "semantic-segmentation" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "recall", "term": "Recall", "aka": [ "Sensitivity", "True Positive Rate" ], "category": "evaluation", "short": "Of everything real, how much the model found — the missed-things meter.", "definition": "Recall answers: of all the buildings that actually exist, what fraction did the model find? It is true positives divided by everything real (true positives plus false negatives). High recall means little slips past; low recall means real structures — and the people in them — go unmapped. Recall says nothing about false alarms: a model that flags every pixel as 'building' achieves perfect recall while being useless. So recall is always paired with precision, and the right balance depends on the mission. In humanitarian mapping, misses are often costlier than false alarms — an unflagged village receives no aid, while a false flag merely costs a reviewer a moment.", "example": "Ground truth says a district contains 500 buildings; the model finds 425 of them. Recall is 0.85 — but the 75 misses cluster in one riverside settlement with unusual thatched roofs, exactly the community a flood response most needed to see.", "related": [ "precision", "f1-score", "confusion-matrix", "building-footprint", "humanitarian-mapping" ], "source": "Standard information-retrieval and detection metrics (van Rijsbergen, Information Retrieval, 1979); COCO detection evaluation (cocodataset.org)" }, { "slug": "remote-mapping", "term": "Remote Mapping", "aka": [ "Armchair Mapping" ], "category": "mission", "short": "Mapping a place you've never been by tracing satellite imagery — powerful at scale, but no substitute for local knowledge.", "definition": "Remote mapping — sometimes called armchair mapping — is contributing to the map of a place you have never visited, by tracing features from satellite or aerial imagery. It is the engine of humanitarian mapping's scale: a volunteer in Oslo can outline a thousand rooftops in Malawi in an evening, something no field survey could match. But imagery only shows so much. A remote mapper cannot read a shop sign, know that a traced track floods every March, or tell a home from a grain store. That is why remote mapping is deliberately paired with local validation: remote volunteers provide the base geometry fast, and local mappers add names, attributes, and corrections. The same humility applies doubly to AI models, which are remote mappers with even less context.", "example": "After a cyclone, remote volunteers trace damaged buildings across an entire coastline within days. A local YouthMappers chapter then walks the priority neighborhoods, discovering that several 'destroyed' buildings were actually under construction — a correction only feet on the ground could make.", "related": [ "mapper", "satellite-imagery", "youthmappers", "missing-maps", "validate" ], "source": "wiki.openstreetmap.org — Armchair mapping; missingmaps.org; qukaizen-geoai/docs/LANDSCAPE.md" }, { "slug": "remote-sensing", "term": "Remote sensing", "category": "imagery", "short": "Measuring things without touching them: sensors reading the radiation a surface reflects or emits.", "definition": "Remote sensing is the science of learning about an object from a distance, without physical contact. In earth observation it means instruments — on satellites, aircraft, or drones — measuring electromagnetic radiation that the surface reflects (sunlight) or emits (heat). Because different materials reflect different wavelengths in characteristic ways, those measurements can be turned into maps: vegetation, water, bare soil, and rooftops each have a spectral signature. Everything downstream in geospatial AI rests on this idea: an image is not just a picture but a grid of physical measurements, which is why bands beyond visible light, calibration, and resolution all matter to what can honestly be inferred from it.", "example": "A newcomer asks how a satellite can tell a flooded field from a dry one when both look brown in a photo. The answer is remote sensing: water absorbs near-infrared light almost completely, so in that invisible band the flooded field goes nearly black while dry soil stays bright.", "related": [ "earth-observation", "spectral-band", "satellite-imagery", "near-infrared" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "review", "term": "Review", "aka": [ "Analyst review", "geoai review" ], "category": "loop", "short": "The analyst gate: a human examines each prediction with its evidence in a localhost MapLibre UI before anything leaves the machine.", "definition": "Review is where a human takes over from the model — nothing produced during inference leaves the machine until an analyst has looked at it. The design is a localhost web interface built on MapLibre, sitting outside the sandbox and reading the immutable result directory. For each candidate it shows before/after imagery, the evidence regions the model pointed to, alternative explanations, raw and calibrated confidence, the model and runtime versions, and the sandbox receipt, with approve/correct/uncertain controls. The model cannot operate the UI or approve its own output. Per ADR-0002 this surface is analyst-only — a professional triage gate, deliberately never a volunteer app with accounts or gamification. The review UI is M2 ROADMAP; at M0 it is design only.", "example": "An analyst opens the review UI over morning coffee. Candidate 47 claims a bridge is obstructed; she pans the evidence region, sees the shadow the model mistook for debris, clicks 'correct', and marks two genuine washouts 'approve'. Only after her pass does the run become eligible for export — her corrections also become future training signal.", "related": [ "infer", "export", "review-ui", "maplibre", "human-in-the-loop" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (\"Human interface\", \"Result contract\"); docs/decisions/0002-volunteer-experience-rides-mapswipe.md Decision 2; docs/ROADMAP.md M2; read 2026-07-12" }, { "slug": "review-ui", "term": "Review UI", "aka": [ "Human review interface" ], "category": "stack", "short": "The localhost analyst interface: a MapLibre map with predictions, imagery evidence, and the run's receipt side by side — design stage.", "definition": "The review UI is where a human meets the model's output. Designed as a localhost web interface built on MapLibre, it sits outside the sandbox and reads immutable results: before/after imagery, the evidence regions a prediction points at, the model's observation and alternative explanations, raw and calibrated confidence, the sandbox receipt, and approve/correct/uncertain controls. Two boundaries define it. First, the model cannot operate the UI or approve its own output — review authority is structurally human. Second, the UI talks only to the control plane, never directly to the inference worker. Status honesty: this is ROADMAP design in ARCHITECTURE.md — no UI code exists at M0. Every human verdict it will capture is also future Nucleus bake corpus.", "example": "An analyst opens the local map after a run: a flagged road segment glows on imagery, the model's claim ('debris blocking carriageway') sits beside an alternative ('shadow from adjacent structure'), and the receipt confirms zero-egress enforcement. The analyst clicks correct, and that judgment is recorded.", "related": [ "maplibre", "human-in-the-loop", "review", "execution-receipt", "geoai-runtime" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (Human interface section); qukaizen-geoai/docs/decisions/0001-repo-boundaries-and-pinned-contracts.md" }, { "slug": "sandbox", "term": "Sandbox", "aka": [ "Process sandbox", "Isolation boundary" ], "category": "runtime", "short": "An enforced box around a process, controlling what it may read, write, execute, and (not) reach over the network.", "definition": "A sandbox is an enforced boundary around a running process that controls what it may read, what it may write, what it may execute, and what it may reach — with 'nothing' being a valid and here mandatory answer for the network. Enforcement comes from the operating system or hypervisor, not the application itself: Linux network namespaces plus seccomp and Landlock, the macOS Seatbelt facility, Windows AppContainer, or a microVM with no virtual network card at all. In qukaizen-geoai's design, the inference worker and engine run entirely inside a sandbox defined by a versioned profile; the design also specifies rejection of dangerous inputs at the boundary — URLs, symlinks escaping the bundle, undeclared files, mismatched hashes. First implementation is the M1 macOS Seatbelt backend (ROADMAP).", "example": "Think of a workshop with one door: raw materials are shelved inside before work begins (read-only inputs), finished pieces go out through a single chute (write-only output directory), and there is no phone on the wall. Whatever happens inside — even a saboteur — cannot call out or wander the building.", "related": [ "secure-zero-egress-claw", "sandbox-profile", "enforcement-level", "inference-bundle", "zero-egress" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§2 sandbox rejections, §3 cross-platform enforcement backends); qukaizen-geoai/docs/ROADMAP.md (M1 item 3)" }, { "slug": "sandbox-profile", "term": "Sandbox profile", "aka": [ "geoai.sandbox-profile/v1alpha1" ], "category": "runtime", "short": "The versioned, declarative isolation policy a run pins by digest — network, filesystem, process, device, and resource rules as data.", "definition": "A sandbox profile is the isolation policy written down as versioned data rather than buried in application code. The geoai.sandbox-profile/v1alpha1 schema (shipped draft with worked example) structures it into sections: network (mode, DNS, socket rules), filesystem (root, inputs, model store, output, host paths, temp quota), process (shell, child processes, dynamic libraries, environment, secrets), devices (CPU/GPU/NPU allowed; USB, camera, microphone denied), resources (memory, CPU time, process count, output size), capabilities (tools, plugins, dynamic code, model downloads — all deny), and enforcement (minimum level, fail-closed flag). Because it is a document, it has a digest, and every dispatch pins the exact profile version by that digest — so the receipt can say precisely which policy text was specified to govern the run. Named profiles map to platform backends (Seatbelt, netns+seccomp+Landlock, AppContainer, microVM).", "example": "Security review of a run becomes reading one JSON document: did this profile allow child processes? (allowlisted only.) Could it see $HOME? (hostPaths: deny.) A policy change is a new version with a new digest — visible in every subsequent receipt, never a silent code edit.", "related": [ "secure-zero-egress-claw", "sandbox", "enforcement-level", "fail-closed", "execution-receipt" ], "source": "qukaizen-geoai/schemas/geoai.sandbox-profile.v1alpha1.schema.json; qukaizen-geoai/schemas/examples/sandbox-profile.example.json; qukaizen-geoai/docs/ARCHITECTURE.md (§3)" }, { "slug": "satellite-imagery", "term": "Satellite imagery", "aka": [ "Satellite images", "Spaceborne imagery" ], "category": "imagery", "short": "Pictures of Earth's surface taken by sensors on orbiting satellites — the raw material of remote mapping.", "definition": "Satellite imagery is photographs of Earth taken from space. Sensors on orbiting satellites record radiation reflected or emitted by the surface and store it as gridded pixel values, each pixel covering a known patch of ground. Different satellites trade coverage against detail: free public missions like Sentinel-2 image whole continents every few days at 10-meter pixels, while commercial satellites resolve individual rooftops at 30 centimeters but cost money and cover less. For humanitarian mapping, satellite imagery is the input everything else consumes — volunteers trace buildings from it, models predict footprints from it, and its license determines what anyone may legally do with the results.", "example": "After an earthquake in a rural district, no one on the ground can survey which villages still have intact buildings. A satellite passes over the next morning; within hours, mappers and models are working from those images to build the first damage picture — without anyone setting foot in the area.", "related": [ "remote-sensing", "aerial-imagery", "spatial-resolution", "imagery-licensing", "remote-mapping" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed.; NASA Landsat science (landsat.gsfc.nasa.gov)" }, { "slug": "secure-zero-egress-claw", "term": "secure-zero-egress-claw", "aka": [ "The claw profile" ], "category": "runtime", "short": "The named sandbox profile: network none, read-only inputs, write-only output, fail-closed — a versioned policy, not app code.", "definition": "secure-zero-egress-claw is the named sandbox profile that qukaizen-geoai's inference runs are specified to execute under. It is a versioned, declarative policy document — not application code — declaring: network mode none with DNS disabled; an ephemeral filesystem root with read-only inputs and model store and a write-only output directory; no shell, no child processes beyond an allowlist, a cleared environment, no secrets; devices limited to CPU/GPU/NPU with camera, microphone, and USB denied; bounded memory, CPU time, and output size; and fail-closed enforcement (minimum level 'enforced'). The name descends from qukaizen-dac's coined 'zero-claw' profile: a container with no claws cannot reach out and grab anything. Design stage — the M1 build implements the macOS Seatbelt backend first.", "example": "A run dispatch pins the profile by name, version, and digest: {\"profile\": {\"name\": \"secure-zero-egress-claw\", \"version\": \"1.0.0\", \"digest\": \"sha256:c140...\"}}. Auditors later read the receipt and know exactly which policy text — byte for byte — was specified to govern that run.", "related": [ "sandbox-profile", "sandbox", "fail-closed", "zero-egress", "zero-claw-exec" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§3, profile YAML and zero-claw lineage); qukaizen-geoai/schemas/examples/sandbox-profile.example.json" }, { "slug": "semantic-segmentation", "term": "Semantic Segmentation", "aka": [ "pixel-wise classification" ], "category": "models", "short": "Labeling every pixel of an image by class — building, road, water — rather than boxing whole objects.", "definition": "Semantic segmentation assigns a class to every single pixel in an image: this pixel is building, that one is road, that one is background. The output is a mask the same size as the input, which is why it suits mapping — masks trace shapes, and shapes become polygons. The dominant architecture lineage descends from U-Net, an encoder-decoder network with skip connections originally built for biomedical images and now the workhorse of remote-sensing baselines, including fAIr's building-detection models. Its limitation is that it labels stuff, not things: two touching buildings can merge into one blob, which is why post-processing and instance-aware methods exist.", "example": "A fAIr building model segments an aerial tile of a Tanzanian town: roof pixels light up as 'building', everything else stays background. Vectorization then traces each blob into a polygon — and a reviewer splits the one blob that is actually two adjoining houses.", "related": [ "building-footprint", "object-detection", "fair", "raster-data", "vector-data" ], "source": "arXiv:1505.04597 — U-Net: Convolutional Networks for Biomedical Image Segmentation; hotosm fAIr documentation (github.com/hotosm/fAIr)" }, { "slug": "sentinel-2", "term": "Sentinel-2", "aka": [ "Copernicus Sentinel-2" ], "category": "imagery", "short": "ESA/Copernicus workhorse: 13-band multispectral imaging at up to 10 m, ~5-day revisit, free and open.", "definition": "Sentinel-2 is the optical imaging mission of Europe's Copernicus earth-observation program, operated by ESA — a pair of identical satellites carrying a 13-band multispectral instrument. Its visible and near-infrared bands resolve 10 meters, others 20 or 60 meters, and the twin-satellite constellation revisits most of the planet about every five days. All data is free and openly licensed. That combination — moderate resolution, rich bands, rapid revisit, zero cost — makes Sentinel-2 the default choice for monitoring change: floods, crops, deforestation, urban growth. It cannot resolve individual small buildings, so in humanitarian mapping it typically answers 'where and when did things change?' while higher-resolution imagery answers 'trace exactly what is there.'", "example": "A river basin floods on a Tuesday. By the weekend a Sentinel-2 pass has imaged it; an analyst composites the shortwave-infrared and NIR bands, maps the water extent at 10 meters, and hands coordinators a same-week flood outline — for free, from an archive anyone on the team could have downloaded.", "related": [ "earth-observation", "multispectral", "landsat", "near-infrared", "cloud-cover" ], "source": "ESA Sentinel Online — Copernicus Sentinel-2 documentation" }, { "slug": "sha-256", "term": "SHA-256", "aka": [ "SHA-2 256-bit", "sha256 digest" ], "category": "runtime", "short": "The cryptographic fingerprint function behind every digest here: 64 hex characters, collision-resistant, standardized by NIST.", "definition": "SHA-256 is a cryptographic hash function: it reads any input — a 4 GB GeoTIFF or a five-byte string — and produces a fixed 256-bit fingerprint, written as 64 hexadecimal characters. Two properties make it the backbone of this system's trust story: changing even one input bit produces a completely different, unpredictable output, and it is computationally infeasible to find two different inputs with the same fingerprint (collision resistance) or to forge an input matching a given fingerprint. Every digest in qukaizen-geoai's schemas is a SHA-256 value with the 'sha256:' prefix — the schemas literally enforce the pattern ^sha256:[0-9a-f]{64}$ — covering bundles, assets, models, tasks, profiles, and outputs. It is standardized in NIST FIPS 180-4 and universally available.", "example": "The worker is handed a file claimed to be the declared road geometry. It hashes the bytes, gets sha256:a3d1..., and compares against the manifest. A single flipped bit anywhere in the file — corruption or tampering — yields a wildly different digest and an immediate rejection.", "related": [ "content-addressing", "bundle-manifest", "execution-receipt", "determinism" ], "source": "FIPS 180-4 (NIST) — Secure Hash Standard; qukaizen-geoai/schemas/geoai.receipt.v1alpha1.schema.json ($defs.digest pattern)" }, { "slug": "spatial-autocorrelation", "term": "Spatial Autocorrelation", "aka": [ "Tobler's First Law" ], "category": "evaluation", "short": "Near things resemble each other — Tobler's observation, and the reason random splits flatter geo models.", "definition": "Spatial autocorrelation is the tendency of nearby places to be similar: adjacent tiles share soil, vegetation, building styles, and the same satellite pass. Tobler put it memorably — everything is related to everything else, but near things are more related than distant things. For evaluation this is the crucial complication: statistics assumes test examples are independent of training examples, but a test tile 200 meters from a training tile is almost a copy of it. Random splits therefore systematically overestimate how well a geo model generalizes, sometimes dramatically. Spatial autocorrelation is not a flaw to eliminate — it is a property of the world to respect, and spatial splits with buffers are how evaluation respects it.", "example": "Two neighboring tiles of a Tanzanian town show the same tin roofs, the same red soil, the same afternoon shadows. Put one in training and one in testing and the model 'predicts' the second almost by memory — which is why the honest test tile is in another district entirely.", "related": [ "spatial-split", "data-leakage", "spatially-honest-evaluation", "satellite-imagery" ], "source": "Tobler 1970 — A Computer Movie Simulating Urban Growth in the Detroit Region, Economic Geography 46 (first law of geography); Roberts et al. 2017 — Cross-validation strategies…, Ecography 40:913-929" }, { "slug": "spatial-resolution", "term": "Spatial resolution", "category": "imagery", "short": "How small a thing you can actually see in an image — the property that decides what's mappable.", "definition": "Spatial resolution describes the level of ground detail an image captures, usually stated as the size of ground each pixel covers. It is the single property that most determines what a given image can be used for. At 30 meters (Landsat) you can map forests and lakes but a whole village is a few pixels. At 10 meters (Sentinel-2) roads and large buildings emerge as shapes. At 50 centimeters or better, individual houses, footpaths, and vehicles become traceable — this is the regime humanitarian building-mapping needs. Higher resolution costs money, storage, and coverage, so choosing imagery is always a negotiation between detail, area, revisit frequency, and license.", "example": "A mapathon coordinator receives 10-meter imagery of an informal settlement and asks why volunteers can't trace the houses. Each dwelling is roughly 5 meters across — smaller than a single pixel. The task is impossible until sub-meter imagery arrives; resolution, not effort, was the constraint.", "related": [ "ground-sample-distance", "satellite-imagery", "zoom-level", "building-footprint" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed." }, { "slug": "spatial-split", "term": "Spatial Split", "aka": [ "Geographic Split", "Spatial Block Split" ], "category": "evaluation", "short": "Dividing train and eval data by geography — regions or grid blocks — instead of by random rows.", "definition": "A spatial split divides data for training and evaluation by place rather than by random selection: whole districts, watersheds, or grid blocks go entirely to one side or the other. This exists because random splits scatter neighboring, near-identical tiles across both sides, letting the model score on scenery it effectively trained on. Common designs include leaving out whole regions, checkerboard block splits, and buffered splits that also discard a strip between train and eval zones so nothing touches. In qukaizen-geoai's design, the spatial split is not improvised by whoever runs the evaluation: it is authored in the control plane (qukaizen-dac), which owns geographic train/test splits, and recorded by digest so the exact split is verifiable later.", "example": "Instead of shuffling 40,000 tiles randomly, the control plane assigns three entire provinces to evaluation and buffers 5 km around them. The model never trains within sight of its exam — and the split's digest lands in the run record so anyone can reproduce it.", "related": [ "spatially-honest-evaluation", "spatial-autocorrelation", "train-test-split", "control-plane", "data-as-code" ], "source": "Roberts et al. 2017 — Cross-validation strategies for data with temporal, spatial, hierarchical, or phylogenetic structure, Ecography 40:913-929; qukaizen-geoai/docs/ARCHITECTURE.md (DaC owns geographic train/test splits); qukaizen-geoai/CLAUDE.md" }, { "slug": "spatially-honest-evaluation", "term": "Spatially Honest Evaluation", "aka": [ "Geographically Honest Evaluation" ], "category": "evaluation", "short": "The house rule: never score a geo model on geography it trained near — split by place, and record where the split came from.", "definition": "Spatially honest evaluation means never testing a geographic model on places it effectively already saw during training. Because nearby locations look alike, a model tested on tiles adjacent to its training tiles gets credit for memorizing a neighborhood, not for understanding buildings or roads. The honest discipline is to divide train and evaluation data by geography — whole regions or grid blocks held apart — and to make that division auditable. In qukaizen-geoai's design (M0, design stage), the spatial split is authored by the control plane (qukaizen-dac) and recorded by digest in every evaluation output, so anyone can verify which geography was held out. The repo's shipping gate states it plainly: evaluation outputs never mix train and eval geography.", "example": "A building-detection model trained on the north half of a Mozambican district scores 0.94 when tested on adjacent southern tiles — and 0.71 when tested on a district it never saw. The first number flatters memorized rooftop styles; the second is what field teams will actually experience.", "related": [ "spatial-split", "spatial-autocorrelation", "data-leakage", "control-plane", "sha-256" ], "source": "qukaizen-geoai/CLAUDE.md (gating: never mix train/eval geography; splits from control plane, recorded by digest); qukaizen-geoai/docs/LANDSCAPE.md (spatially honest evaluation kit); Roberts et al. 2017 — Cross-validation strategies for data with temporal, spatial, hierarchical, or phylogenetic structure, Ecography 40:913-929" }, { "slug": "specialist-model", "term": "Specialist Model", "aka": [ "domain-specialist", "small specialist" ], "category": "models", "short": "A small model that owns one domain deeply instead of knowing everything shallowly — cheaper, faster, auditable.", "definition": "A specialist model is a deliberately small model trained to be excellent at one narrow domain rather than passable at everything. The bet: for a well-bounded task like judging geo observations, a few billion focused parameters can match or beat a frontier generalist while running on local hardware with no cloud dependency. In this workspace the specialist is what qukaizen-nucleus is for: its pipeline is designed to bake a small MoE VLM geo-specialist from reviewed (observation, verdict, human win/loss/tie) corpora — every human review in the loop becomes future training signal. That geo-specialist is ROADMAP; until it exists, the v0 design runs off-the-shelf models.", "example": "Today an off-the-shelf 4B model judges tiles adequately but generically. After thousands of reviewed verdicts accumulate, Nucleus bakes a specialist that has effectively absorbed those human corrections — it knows that a metal glint in Sahel imagery is usually a roof, not a vehicle.", "related": [ "nucleus", "fine-tuning", "vision-language-model", "human-in-the-loop" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (Nucleus-baked small MoE VLM, ROADMAP); qukaizen-nucleus/TECH_BRIEF.md" }, { "slug": "spectral-band", "term": "Spectral band", "aka": [ "Band" ], "category": "imagery", "short": "One slice of the electromagnetic spectrum that a sensor records as a separate image layer.", "definition": "A spectral band is a defined range of wavelengths that a sensor measures separately. An ordinary camera records three bands — red, green, blue — matching human vision, but satellite sensors are not limited to what eyes can see: they add bands in the near-infrared, shortwave infrared, and beyond. Each band is stored as its own grayscale layer of the same scene, and each reveals different physics: chlorophyll reflects strongly in near-infrared, water absorbs it, moisture and minerals show in shortwave infrared. Band combinations are the raw ingredients for indices like NDVI and for machine-learning inputs that give models information no visible photo contains.", "example": "Two fields look identically green in a normal photo. Load the same scene's near-infrared band and one glows bright while the other is dull — the first is healthy crops, the second is drought-stressed vegetation weeks from failing. The extra band saw what the eye could not.", "related": [ "near-infrared", "multispectral", "ndvi", "remote-sensing" ], "source": "Lillesand, Kiefer & Chipman — Remote Sensing and Image Interpretation, 7th ed.; ESA Sentinel Online — Copernicus Sentinel-2 documentation" }, { "slug": "tasking-manager", "term": "Tasking Manager", "aka": [ "HOT Tasking Manager", "TM" ], "category": "mission", "short": "HOT's coordination tool that splits large mapping areas into small task squares so volunteers don't collide.", "definition": "The Tasking Manager is HOT's open-source coordination tool for collaborative mapping. It solves a simple but critical problem: when hundreds of volunteers map the same region at once, they would duplicate and overwrite each other's work without coordination. The Tasking Manager splits a project area into a grid of small task squares; each mapper locks one square, maps it, and marks it done, and experienced mappers later validate completed squares before the project counts as finished. Projects carry instructions, imagery sources, and priority levels, so a disaster activation can direct effort exactly where responders need it first. The lock-map-validate cycle is the backbone of every large humanitarian mapping campaign and most mapathons.", "example": "At a mapathon, two hundred volunteers open the same earthquake-response project. Each clicks a square of the grid, which locks instantly so nobody else gets it. One mapper finishes her square in twenty minutes and marks it 'completely mapped'; days later a validator reviews it, fixes two misaligned buildings, and stamps it green.", "related": [ "hot", "mapathon", "mapper", "validate", "openstreetmap" ], "source": "tasks.hotosm.org; github.com/hotosm/tasking-manager; wiki.openstreetmap.org — Tasking Manager" }, { "slug": "telemetry", "term": "Telemetry", "aka": [ "Engine events", "In-process observability" ], "category": "runtime", "short": "Engine events — tokens emitted, layers loaded and evicted — published on an in-process bus and logged locally: observability without egress.", "definition": "Telemetry here means the stream of events an inference engine emits about its own operation — tokens generated, model layers or MoE experts loaded and evicted, memory pressure, timings. In most software, 'telemetry' implies sending such data to a vendor, which is exactly what zero egress forbids; qukaizen-geoai's design resolves the tension by keeping every event on the machine. The embedded engine (QueueLLM) publishes events on an in-process bus; the worker is specified to capture them into the run's immutable result directory — metrics.json and logs.ndjson alongside the receipt — where they support debugging, performance work, and audit. Observability without a phone-home path: the profile denies the network, so even a misconfigured logger cannot report out. Design stage; the result-directory contract is part of the M1 worker.", "example": "After a slow run, an engineer opens metrics.json locally and sees expert-cache evictions spiking mid-generation — the memory budget was too small for the MoE model's active experts. The diagnosis needed rich engine telemetry; not one byte of it ever left the laptop.", "related": [ "aerollm", "execution-receipt", "zero-egress", "layer-streaming" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md ('Result contract': metrics.json, logs.ndjson; §5 engine metrics); aerollm public API baselines (engine event bus)" }, { "slug": "the-loop", "term": "The Humanitarian Mapping Loop", "aka": [ "The Loop", "Humanitarian mapping cycle" ], "category": "loop", "short": "The full cycle: open imagery and OSM labels feed local models, humans review and validate, and reviewed edits improve the next model.", "definition": "The loop is the whole journey a map prediction takes, from a satellite photo to a verified edit on the shared world map. Open imagery and OpenStreetMap labels are acquired and hashed; an immutable bundle is materialized and verified; a model runs offline in a sandbox on local hardware; an analyst reviews the predictions; an explicit export hands them to MapSwipe volunteers for validation; only human-validated results reach OpenStreetMap; and reviewed outcomes feed better models. In qukaizen-geoai's design the stages are named ACQUIRE, MATERIALIZE, VERIFY, INFER, REVIEW, EXPORT, and VALIDATE — with a structural rule that no single process may acquire, infer, and publish, and no AI prediction ever enters OSM without human review. The runtime is ROADMAP (M0: docs and schemas only).", "example": "A flood cuts roads in Mozambique. Imagery is fetched and hashed on Monday, bundled Tuesday, run through a local model with the network physically denied, reviewed by an analyst Wednesday, exported to a MapSwipe validation project, swiped by volunteers worldwide, and by Friday only the human-confirmed road blockages appear in OpenStreetMap for relief planners.", "related": [ "acquire", "infer", "validate", "humanitarian-mapping", "human-in-the-loop" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (\"Separate acquire, infer, and publish\"), docs/ROADMAP.md, docs/decisions/0002-volunteer-experience-rides-mapswipe.md; read 2026-07-12" }, { "slug": "train-test-split", "term": "Train/Test Split", "aka": [ "Train/Eval Split" ], "category": "evaluation", "short": "The basic discipline of dividing data into a set the model learns from and a separate set it is graded on.", "definition": "A train/test split is the foundational habit of machine learning evaluation: divide the data before training, learn only from the training portion, and grade only on the test portion. The point is to measure generalization — performance on things the model has not seen — rather than memorization, which any large model can fake. Often a third validation slice is carved out for tuning decisions, keeping the test set untouched until the end. The split's design carries assumptions: a random split assumes examples are independent, which holds for shuffled photographs but fails for map tiles, where neighbors are near-duplicates. Geographic data therefore upgrades this basic discipline to a spatial split — same principle, honest boundaries.", "example": "A fAIr-style training run on 10,000 labeled tiles keeps 2,000 aside from the start. The model never trains on them, and the final report is computed only there — the mapping-world equivalent of grading students on problems that were not in the homework.", "related": [ "spatial-split", "holdout", "data-leakage", "fair", "training-label" ], "source": "Standard machine-learning textbook treatment (Hastie, Tibshirani & Friedman, The Elements of Statistical Learning); Roberts et al. 2017 — Cross-validation strategies…, Ecography 40:913-929 (why the geographic upgrade is needed)" }, { "slug": "training-label", "term": "Training Label", "aka": [ "label", "annotation" ], "category": "models", "short": "The human-made answer a model learns from — in this world, usually OSM-derived polygons with their own provenance.", "definition": "A training label is the answer sheet: the human-created output paired with each input that a model learns to imitate. For building detection, the label for an imagery tile is the set of footprint polygons humans drew there — typically extracted from OpenStreetMap. Labels carry their own quality and provenance concerns, separate from the imagery's: OSM coverage is uneven, so a model trained where OSM is complete learns 'unmapped' means 'empty', which is exactly backwards for humanitarian work targeting unmapped places. This world's licensing discipline follows: label provenance is recorded separately from imagery, model, and split provenance, because open polygons do not make the source imagery open.", "example": "To fine-tune a building detector for a Ugandan district, a mapathon first completes OSM footprints across a few training areas. Those fresh polygons, clipped to tiles, become the labels — and the manifest records which OSM changesets they came from.", "related": [ "openstreetmap", "ground-truth", "fine-tuning", "imagery-licensing", "mapathon" ], "source": "qukaizen-geoai/docs/LANDSCAPE.md (critical licensing rule; label provenance recorded separately); hotosm fAIr documentation (github.com/hotosm/fAIr)" }, { "slug": "validate", "term": "Validate", "aka": [ "Volunteer validation", "Swipe validation" ], "category": "loop", "short": "MapSwipe volunteers swipe through the reviewed predictions; only human-validated results ever land in OpenStreetMap.", "definition": "Validate is the crowd's turn: after export, real people confirm or reject each prediction before the map changes. Per ADR-0002, validation happens inside MapSwipe's own app — a swipe-based mobile/web experience from an independent community with over 215 million swipes — via fAIrSwipe-style validation projects, not any app this project operates. QuKaiZen's contribution to volunteers is invisible queue quality: calibrated ordering, stratified samples with high-confidence controls, provenance behind every candidate. The structural rule closing the loop is absolute: AI predictions are never pushed into OpenStreetMap directly; only human-validated results proceed, and the validation outcomes — votes, disagreement, timing — feed the evaluation kit and future model improvement. This end-to-end path is the target design; the connecting adapters are ROADMAP.", "example": "On a bus, a teenager opens MapSwipe and swipes through building candidates from the Malawi run — tap for yes, swipe for no — never knowing which local machine produced them. Where enough volunteers agree, an experienced mapper confirms the edit in OpenStreetMap; where they disagree, the tile goes back for expert eyes.", "related": [ "export", "the-loop", "mapswipe", "openstreetmap", "crowdsourcing" ], "source": "qukaizen-geoai/docs/decisions/0002-volunteer-experience-rides-mapswipe.md; docs/ROADMAP.md (\"Do not push AI predictions directly into OSM\"); docs/LANDSCAPE.md strategic table; read 2026-07-12" }, { "slug": "vector-data", "term": "Vector data", "category": "imagery", "short": "The points-lines-polygons data model: discrete features with coordinates and attributes; what OSM is.", "definition": "Vector data represents the world as discrete geometric features — points, lines, and polygons defined by coordinates — each carrying attributes describing what it is. A well is a point, a road a line, a building footprint a polygon tagged with what's known about it. Unlike a raster, vector data has no inherent resolution: a polygon is exact at any zoom, tiny to store, and directly editable feature by feature. OpenStreetMap is fundamentally a vector dataset — nodes, ways, and tags. The core rhythm of AI-assisted mapping is crossing between the models: rasters (imagery) go in, vectors (footprints as GeoJSON polygons) come out, and humans review the vectors.", "example": "A district's imagery weighs 30 gigabytes; the 12,000 building footprints traced from it weigh 4 megabytes of polygons and fully describe where every structure stands. Responders route deliveries against the vectors — the imagery already did its job and is no longer needed in the field.", "related": [ "raster-data", "geojson", "openstreetmap", "building-footprint" ], "source": "IETF RFC 7946 — The GeoJSON Format; wiki.openstreetmap.org — Slippy map tilenames / Zoom levels" }, { "slug": "verify-bundle", "term": "Verify", "aka": [ "Bundle verification", "dac verify" ], "category": "loop", "short": "Before any run, every digest in the bundle is re-checked and anything undeclared, remote, or escaping is rejected outright.", "definition": "Verify is the checkpoint between packing and running: prove the sealed box is exactly what it claims to be, and refuse to run otherwise. In the design, the verifier re-computes and checks every content hash in the bundle manifest and rejects an explicit list of hazards: `http://` or `https://` inputs, arbitrary absolute paths, symlinks that escape the bundle, mismatched hashes, undeclared files, unknown task versions, unsupported model capabilities, and missing output schemas. The stance is fail-closed — one bad file fails the whole bundle, no warnings-and-continue. The bundle verifier is the first component of the M1 thin vertical slice (ROADMAP; no code exists yet at M0), and its result is designed to be recorded in the run's execution receipt.", "example": "A teammate hand-edits a bundle to add one extra GeoTIFF they forgot. Verification fails immediately: the file is not declared in manifest.json, so the run refuses to start. The fix is to go back and re-materialize — the bundle is immutable by design, and undeclared inputs never reach the model.", "related": [ "materialize", "infer", "bundle-manifest", "sha-256", "fail-closed" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md §2 (the sandbox rejection list) and §4 (worker steps 1–2); docs/ROADMAP.md M1 item 1; read 2026-07-12" }, { "slug": "vision-language-model", "term": "Vision-Language Model", "aka": [ "VLM", "multimodal model" ], "category": "models", "short": "A model that takes images as input and answers in language — look at a tile, describe what it sees.", "definition": "A vision-language model is an AI model that looks at an image and responds in words: ask it about a satellite tile and it can describe buildings, roads, or flooding in plain language, not just output pixel masks. Technically, a vision encoder turns the image into tokens a language model can attend to alongside text. For humanitarian GeoAI this is the endgame shape: one model that both perceives imagery and explains its reasoning so a human reviewer can judge it. In qukaizen-geoai's design this is aspirational, not built — aerollm has no vision input path yet (its ADR 0020 is Proposed), and the Nucleus-baked small geo-specialist VLM is ROADMAP.", "example": "Instead of a segmentation model silently emitting a mask, a geo-VLM shown a MapSwipe tile could answer: 'two rectangular rooflines with hard shadows in the northwest quadrant — likely buildings; the linear feature is a dry streambed, not a road' — a claim a reviewer can check.", "related": [ "computer-vision", "specialist-model", "aerollm", "ai-assisted-mapping" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (v0 engine split and target-state Nucleus-baked MoE VLM); aerollm ADR 0020 (vision input path, Proposed)" }, { "slug": "web-mercator", "term": "Web Mercator", "aka": [ "EPSG:3857", "Spherical Mercator", "Pseudo-Mercator" ], "category": "imagery", "short": "EPSG:3857, the projection behind virtually every web map: square, fast, seamless — and badly distorted near the poles.", "definition": "Web Mercator is the map projection used by essentially all interactive web maps, registered as EPSG:3857. It flattens the globe onto a square, which is exactly what tiled web maps need: the square divides evenly into a pyramid of square tiles, north is always up, shapes stay locally recognizable, and zooming is just cutting squares into smaller squares. That convenience won the web. The price is scale distortion that grows with latitude — Greenland renders as large as Africa though it is a fourteenth the size — and the projection is cut off near the poles entirely. Fine for tracing a building, dangerous for measuring or comparing areas across latitudes without reprojecting.", "example": "A volunteer eyeballs two refugee camps on a web map — one in Norway, one in Kenya — and reports the northern one as far larger. Measured properly, they are nearly the same size; Web Mercator had inflated the high-latitude camp roughly threefold. The projection that makes the map smooth also makes it lie about area.", "related": [ "coordinate-reference-system", "map-tile", "zoom-level", "basemap" ], "source": "EPSG:3857 registry (epsg.org); wiki.openstreetmap.org — Slippy map tilenames / Zoom levels" }, { "slug": "youthmappers", "term": "YouthMappers", "category": "mission", "short": "The global network of university student chapters that map their own communities and support humanitarian projects.", "definition": "YouthMappers is an international network of university student chapters that organizes young people around open mapping. Founded in 2015 with support from USAID's GeoCenter, it has grown to hundreds of chapters across dozens of countries, with especially strong presence in Africa, Asia, and Latin America — often precisely the regions humanitarian mapping serves. Chapters run mapathons, contribute to OpenStreetMap and Missing Maps campaigns, and crucially add something remote volunteers cannot: local knowledge. A student mapping her own city can name streets, verify buildings, and correct what armchair mappers guessed from imagery. The network doubles as a career pipeline, producing many of the geospatial professionals and OSM community leaders in the Global South. It is an independent network unaffiliated with QuKaiZen.", "example": "A YouthMappers chapter in Kampala adopts the informal settlement next to campus. Remote volunteers traced the rooftops months ago; the students walk the lanes with phones, adding shop names, water points, and footpaths no satellite could see — turning outlines into a map locals actually recognize.", "related": [ "mapathon", "mapper", "openstreetmap", "missing-maps", "remote-mapping" ], "source": "youthmappers.org; wiki.openstreetmap.org — YouthMappers" }, { "slug": "zero-egress", "term": "Zero egress", "aka": [ "Zero-egress inference" ], "category": "runtime", "short": "The core promise: during inference, nothing leaves the machine — no packets, no telemetry home, no exceptions — and it must be proven.", "definition": "Zero egress is the promise that while a model is running inference, no data leaves the machine: no network packets, no DNS lookups, no telemetry phoned home, no exceptions for error reporting. It is the load-bearing property of qukaizen-geoai's offline execution plane, designed for humanitarian work where imagery may be sensitive and connectivity untrusted. The repo's central rule is that zero egress must be proven, not merely configured: the design specifies an adversarial test suite that actively attempts every escape channel from inside the sandbox, with the pass/fail result recorded in the run's execution receipt. As of 2026-07-12 this is design stage (M0) — the enforcement and test suite are the first M1 build targets, not running code.", "example": "A laptop in a field office runs flood-damage inference over drone imagery of a village. Even if a hostile instruction were hidden inside an image, the design guarantees it could not make a request, leak coordinates, or fetch a payload — the run's receipt would carry the proof that every escape attempt failed.", "related": [ "egress", "secure-zero-egress-claw", "egress-test-suite", "execution-receipt", "air-gap" ], "source": "qukaizen-geoai/docs/ARCHITECTURE.md (§3 'Prove zero egress rather than merely configuring it'); qukaizen-geoai/CLAUDE.md (gating: 'proven, not configured')" }, { "slug": "zoom-level", "term": "Zoom level", "aka": [ "z", "Zoom" ], "category": "imagery", "short": "z in the tile scheme: each level doubles resolution; z18 is where building tracing lives.", "definition": "Zoom level is the z in a map tile's z/x/y address, and it sets how much world each tile shows. At z0 a single tile holds the whole planet; every increment splits each tile into four, doubling linear resolution, so zoom n contains 4^n tiles. In practice the levels have distinct personalities: around z10 you see a whole city, z14–15 shows the street network, and z18 — where a tile spans roughly 150 meters at the equator, under a meter per pixel with good imagery — is the standard working level for tracing individual buildings. Choosing a task's zoom level is choosing what detail volunteers and models can perceive.", "example": "A mapping campaign initially serves tiles at z16 and volunteers keep marking dense settlements as 'maybe' — the huts are smudges. Re-issuing the same area at z18 quadruples the pixel count per building, and the maybe-rate collapses: the zoom level, not volunteer skill, had capped accuracy.", "related": [ "map-tile", "spatial-resolution", "web-mercator", "mapswipe" ], "source": "wiki.openstreetmap.org — Slippy map tilenames / Zoom levels" } ] }