Matt mentioned a number that surprised me. About 4.5 million people in the United States have taken AP Human Geography. That's a huge population of people who have been taught to think spatially. Yet very few of them have job titles that include GIS or geography. Chris Tucker put it simply. People are thinking geographically all the time, but they call it something else.

This is something I have seen throughout my own career. Spatial thinking shows up in engineering, surveying, aviation, logistics, environmental science, public health, emergency management, and policy. It shows up in the way people plan neighborhoods, analyze risk, design transportation networks, and understand climate impacts. It shows up in the way we make sense of the world. Most of the time, nobody uses the word geography. The thinking is there. The label is not.

In his podcast, Matt asks Tucker to name five careers that do not sound geographic but rely heavily on spatial skills. Surveying. CAD and the built environment. Aviation. Marine navigation. Conservation. I could add many more. Hydrology. Urban planning. Forestry. Infrastructure design. Environmental compliance. Even software architecture has spatial elements when you think about systems as landscapes. I myself started out with summers working for a land surveyor in high school, long before I switched majors to study GIS and remote sensing.

The point is simple. Spatial thinking is not a niche skill. It is a foundational way of understanding relationships, patterns, and context. It helps people see how things connect. It helps them understand how decisions ripple across space and time. It helps them avoid narrow thinking and blind spots. It is one of the most practical forms of critical thinking we have.

Many people struggle to explain what they do for a living. I've been there myself. When your work sits at the intersection of disciplines, the usual labels do not fit. Matt's conversation offers a better way to frame it. If your work involves understanding how things relate across space, you are part of a much larger community of spatial thinkers. You do not need the title to belong to the discipline.

Geography has always been more than maps. It is a way of seeing. It is a way of organizing information. It is a way of understanding systems. It is a way of thinking that shows up everywhere, even when people do not recognize it.

If you have ever felt like your work is hard to describe, consider the possibility that you are doing geography without calling it that. You are part of a tradition that is older than any job title and more relevant than ever in a world shaped by data, movement, and change.

The public sector is entering an era shaped by artificial intelligence, machine readable data, and composable architectures. Agencies will need to rethink how they publish information. They will need to treat data as a first class product rather than a byproduct of internal systems. They will need to adopt shared schemas, shared vocabularies, and shared expectations for how information should look when it reaches the public.

This is not a technical problem alone. It is a trust problem. It is a clarity problem. It is a consistency problem. And it is a problem that can be solved.

What agencies should work toward

Consistent schemas across agencies
Right now every agency publishes data in its own shape. Field names differ. Definitions differ. Formats differ. Even basic concepts like facility identifiers, geographic boundaries, or program codes vary from one dataset to the next. Agencies should work toward shared schemas that can be reused across programs. This would make public data easier to combine, easier to analyze, and easier to validate. It would also reduce the burden on developers who want to build tools on top of government information.

Shared ontologies and controlled vocabularies
Agencies should adopt shared semantic models. SKOS, OWL, and RDF are mature technologies that allow concepts to be defined once and reused everywhere. A shared vocabulary for things like facility types, company identifiers, geographic units, and regulatory concepts would make it easier for the public to understand how different datasets relate to each other. It would also help agencies avoid duplication and inconsistency. This aligns with themes I write about at https://davidgsmith.net, especially around semantic clarity and the value of well structured knowledge.

APIs that are predictable and well documented
The era of AI and machine learning depends on predictable APIs. Agencies should publish data through stable endpoints with clear documentation. They should support pagination, filtering, and metadata that explains how the data was collected. They should avoid one‐off formats and instead adopt standards like JSON‐LD or other machine friendly structures. This would make it easier for developers, researchers, and journalists to build tools that help the public understand government information.

Machine readable metadata and validation rules
Agencies should publish SHACL shapes, schema definitions, and validation rules alongside their data. This would allow tools to automatically check whether a dataset is complete, consistent, and aligned with expectations. It would also help AI systems avoid misinterpretation. When data is self describing, it becomes easier to trust.

Modern publishing pipelines
Agencies should adopt cloud native pipelines that allow data to be ingested, validated, standardized, enriched, and published in a consistent way. This is the same pattern used in modern private sector architectures. It ensures that data is clean, traceable, and ready for public use. It also makes it easier to update datasets regularly without breaking downstream tools.

Transparency about provenance
People want to know where information comes from. Agencies should publish lineage metadata that explains how each dataset was produced. This includes source systems, transformation steps, and quality checks. Provenance builds trust, and trust is essential for public information systems.

Why this matters now more than ever

AI systems are only as good as the data they consume. If agencies want AI tools to help the public understand government information, they need to publish data that is structured, consistent, and semantically rich. They need to adopt standards that make it easy for machines to interpret meaning. They need to think about how APIs, schemas, and ontologies shape the future of civic understanding.

This is not about technology for its own sake. It is about building a foundation for public trust. It is about giving people tools that help them make sense of the world. It is about ensuring that government information is accessible, reliable, and ready for the next generation of applications.

The launch of America.gov is a step. The reaction shows that people care deeply about how information is presented. Agencies should take this moment as an opportunity to modernize their data practices and work toward a future where public information is not only available, but genuinely useful.

According to their press release, this was the milestone product of their new molecular biology wet lab, achieved by deploying an army of 950 AI agents working over 21 hours.

It sounded like a massive leap forward for autonomous science, until researchers in the field began pulling back the curtain.

As it turns out, human scientists had mapped out this exact genetic sequence five years ago without any AI assistance. A 2021 paper by Korn et al. documented the exact same stretch of DNA, described the reverse transcriptase, and even hypothesized the presence of an associated non coding RNA.

While Anthropic properly cited these scientists in their technical preprint paper, they completely scrubbed them from the public facing marketing campaign.

To make matters more complicated, critics pointed out that when Anthropic reran the identical prompt campaign ten more times, the AI missed the genetic structure entirely every single time.

This isn't a story about a useless tool, but it is a textbook example of a dangerous corporate trend. Tech labs are increasingly willing to bypass established norms of academic citation to spin a sci fi narrative about autonomous breakthroughs.

The Danger of First Order Thinking in AI Rollouts

When we look at this situation, it is easy to fall into first order thinking. A first order thinker looks at Anthropic's announcement and focuses entirely on immediate utility: we can deploy an army of software agents to automate biological research, lower human headcount, and speed up discovery.

Second order thinking forces us to ask a much harder set of questions. What happens when an enterprise relies on an autonomous system that hallucinates baseline facts, or completely misses a target on a rerun? If a company brands a genomic pattern matching tool as an independent inventor, what hidden liabilities are we introducing into our workflows when that system encounters an unexpected edge case?

Treating probabilistic pattern matching engines as deterministic, flawless inventors is an expensive mistake. The AI didn't independently deduce a biological truth from first principles. It navigated a massive dataset of existing human knowledge, found a structural pattern, and mapped it across related families. That is an incredibly useful capability, but it is a optimization step, not an immaculate conception.

Why Human judgment is the Ultimate Technical Skill

The real lesson here has less to do with biology and everything to do with how we interact with generative models. Software can now generate an infinite volume of plausible text, code, and hypotheses. Because the output sounds authoritative and is beautifully constructed, our natural instinct is to accept it without friction.

This is exactly where mental passivity becomes incredibly expensive. When we hand over the responsibility of verification to the machine, we inherit a massive blind spot. In production environments, failing to map these second order failure modes is an indefensible exposure.

The professionals who derive the most value from these new toolchains won't be the ones copy pasting trendy prompt templates.

They will be the experts who maintain strong domain knowledge, deep structural discipline, and the willingness to trace every single synthetic claim back to a primary source. AI can supercharge our research workflows, but it can't replace or supply human judgment.

When a model loses attention, it doesn'crash. It simply ignores specific instructions, hallucinates facts that contradict the provided text, or relies heavily on its pre-training weights instead of the in-context data. Understanding why this happens requires looking at the underlying math of the transformer architecture and the physical limitations of memory allocation.

Why Attention Loss Happens
The root cause of context degradation lies in the self-attention mechanism itself. Transformers process text by assigning attention scores between every token and every other token in a sequence. As the sequence grows longer, the model must distribute its attention scores across a vastly larger number of data points.

This creates a dilution effect. If a critical instruction is buried at token 45,000 in a 100,000-token prompt, the raw attention score assigned to that specific instruction becomes mathematically infinitesimal compared to the aggregate attention scores of the surrounding noise. Researchers famously documented this as the "Lost in the Middle" phenomenon, demonstrating that models are highly proficient at retrieving information at the very beginning and very end of a prompt but struggle significantly with information located in the middle.

Hardware constraints also play a major role. To process long sequences without recalculating everything from scratch, models use a Key-Value (KV) cache. The KV cache stores representations of all previous tokens. As the prompt grows, the KV cache scales linearly, consuming massive amounts of GPU VRAM. When models are forced to compress this cache or when rotary position embeddings (RoPE) are stretched beyond their optimal training distribution, the model's spatial awareness of where tokens reside in relation to one another begins to break down.

How to Notice and Measure the Drop
Attention loss is insidious because the model remains fluent. It will confidently generate output that looks correct but misses the core constraints of the prompt. Engineers and researchers use specific frameworks to audit this behavior.

Needle in a Haystack (NIAH) Testing: The most common diagnostic tool is the NIAH evaluation. This involves taking a large block of filler text (the haystack) and inserting a specific, out-of-context fact (the needle) at varying depths. You then prompt the model to retrieve that fact. By plotting the retrieval accuracy on a grid of context length versus insertion depth, you can visualize the exact point where a specific model's attention begins to fail.

Instruction Degradation: Another clear symptom is dropped constraints in complex workflows. If you provide an LLM with a 50-page document and append a five-step formatting rule at the end, a model suffering from attention loss might apply rules one and two but completely ignore rules three through five.

Repetition and Looping: When the KV cache becomes corrupted or overly compressed, models lose track of what they have recently generated. This often results in infinite loops where the model repeats the same paragraph or code block endlessly, unable to attend to the tokens that signal the task is complete.

The Downstream Ramifications
The failure to maintain attention across long contexts creates severe constraints for enterprise AI deployments.

When developers trust a large context window to handle document analysis, attention loss directly translates to missed compliance risks, skipped legal clauses, or ignored software bugs. The illusion of capability is more dangerous than a strict limitation. A model that refuses a 100,000-token prompt forces the developer to find a workaround. A model that accepts the prompt but silently drops 20 percent of the information creates a hidden liability that might not be discovered until the output reaches production.

This unreliability forces teams to build complex, brittle wrappers around their AI agents to double-check their work, eroding the speed and efficiency gains the technology was supposed to provide.

What the Industry is Doing About It

Architectural improvements and novel retrieval methods are actively being deployed to fix the memory bottleneck.

Advanced Positional Encodings: Standard positional encodings struggle when extrapolated to sequence lengths they never saw during training. Techniques like YaRN (Yet another RoPE extensioN) scale the attention mechanism to handle longer contexts without losing the relative distance between tokens, keeping the model anchored even at extreme lengths.

KV Cache Eviction: Rather than storing every single token in the KV cache, researchers are developing methods to identify and keep only the "heavy hitters." Frameworks like StreamingLLM prove that you can maintain high performance by keeping the initial tokens (the attention sink) and the most recent tokens, dropping the middle context entirely for continuous generation tasks.

Ring Attention: To bypass hardware limits, Ring Attention distributes the self-attention calculation across multiple GPUs. This prevents any single chip from running out of memory and allows models to process theoretically infinite context windows by passing the token calculations in a circular network.

Retrieval-Augmented Generation (RAG): The most practical mitigation for developers today is simply avoiding massive context windows altogether. RAG architectures chunk data, store it in a vector database, and only inject the most relevant paragraphs into the prompt at runtime. By keeping the context window small and dense, RAG forces the model to focus entirely on high-signal information, sidestepping the attention dilution problem completely.

The latest edition of the GeoAI and the Law Newsletter lays out a clear message for anyone working at the intersection of geospatial data and artificial intelligence. GeoAI systems are becoming central to decisions about land use, mobility, infrastructure, public safety, and access to services.

These systems do more than just classify pixels or detect objects. They influence how institutions understand people and places. That influence carries real consequences.

In his latest article, Kevin Pomfret points to several recent events that illustrate this shift. Sony Music Publishing and Warner Chappell have sued Anthropic over training data. While that specific case involves music lyrics, the exact same legal mechanics apply to proprietary satellite imagery, copyrighted parcel maps, and scraped mobility data. Meanwhile, Flock Safety is facing scrutiny for how its license plate readers and drones are used, and governments are advancing risk based AI laws that directly affect geospatial tools.

These examples show that GeoAI is now entangled with intellectual property, civil liberties, and regulatory compliance. I have always said that in many ways the technology is the easy part. Governance is the hard part. The field is entering a phase where technical capability is no longer the limiting factor. The limiting factor is trust.

The Need for Clear Definitions
One point that stood out in Pomfret's article is the call for organizations to define what GeoAI means within their own operations. Without a definition, teams cannot agree on which systems fall under governance, which risks matter, or which safeguards apply. A land use classifier, a mobility model, and a mapping tool may seem unrelated, but they all influence decisions about physical space. That influence creates shared responsibilities.

Risk Classification Is Not a Checkbox
His article explains how the EU AI Act and the Colorado AI Act use risk based approaches. My own view is that risk classification is where many organizations will struggle. It is easy to label a system as low risk because it appears purely informational. The problem is that informational systems often become inputs to higher stakes decisions.

Consider a mapping tool built simply to visualize historical flood data. If a municipal government later adopts that same visualization to deny building permits, or if insurers use it to adjust premiums, the risk profile fundamentally changes. The system escalated from an informational display to a decision engine. This is why Pomfret's advice to track intended purpose, deployment geography, affected populations, and downstream decisions is so practical. GeoAI systems do not exist in isolation. They exist within workflows.

Lifecycle Governance Is the Best Sustainable Approach
The article outlines a lifecycle model that covers concept review, design, deployment, oversight, vendor management, documentation, and monitoring. This model reflects how geospatial systems actually behave in the real world. They drift. They expand. They get repurposed. They inherit biases from data coverage, sampling, and proxy variables. They perform differently across regions and demographic groups.

A one time review cannot catch these issues. Continuous monitoring is the only realistic way to maintain trust. Fortunately, organizations do not need to invent this from scratch. Adopting established standards like the NIST AI Risk Management Framework or ISO/IEC 42001 gives teams a foundation to monitor for model drift, data drift, geographic performance gaps, and changes in intended purpose.

Vendor Oversight Is Becoming a Core Competency
The article's section on vendor oversight deserves more attention. Many organizations rely on external GeoAI providers, creating dependencies on training data rights, model limitations, and liability allocation. My experience is that these issues are frequently overlooked until something goes wrong.

A strong vendor oversight process requires asking specific, direct questions during procurement. Buyers must ask how the vendor tests for geographic performance gaps in their training data. They need to establish exactly who assumes liability if the model hallucinates a nonexistent physical feature that impacts a costly infrastructure project.

Documentation Is a Trust Signal
The article lists inventories, impact assessments, model cards, dataset records, data lineage, validation results, approvals, change logs, user notices, and incident response plans. These documents are not just compliance artifacts. They are trust signals. They show that an organization understands its systems and is prepared to explain them. In a field where decisions affect real communities, documentation is part of accountability.

Final Thoughts
The article makes a compelling case that GeoAI governance is a foundation for responsible innovation. GeoAI systems deliver enormous value, but only if they are accurate, lawful, explainable, and worthy of public trust. The organizations that succeed will be the ones that treat governance as a strategic capability rather than a regulatory burden.

The exhibit highlights a recurring pattern in demographic reasoning. Once a society reaches low infant and child mortality, the long‐term replacement level is about 2.1 children per woman. The posters didn't reference this. Instead, they promoted a target that was higher than what stable population dynamics require. The intent was not stability. It was growth. France had just come out of the First World War and was concerned about falling behind Germany in population and industrial capacity.

Gelman points out that the "ideal number of children" is not the same as the number people actually have. Ideals often reflect cultural narratives rather than lived behavior. The posters treated the ideal as a factual requirement. They also ignored the distribution of family sizes. Some households have no children or only one. Policymakers may have assumed that others needed to compensate by having three.

The comments on the post add useful context. One reader notes that the poster's population pyramid shows an expansive structure rather than a stable one. Another points out that immigration is not considered at all. Others mention that similar rhetoric persists today, including recent French political language about "demographic rearmament."

The exhibit is a reminder that demographic claims often blend arithmetic with ideology, something that touched a chord for me particularly after just publishing my book which also explores some similar themes . When governments promote a specific family size as a national duty, the argument usually rests on selective assumptions about stability, growth, and identity. Gelman's post shows how easy it is for a cultural ideal to be presented as a demographic fact, even when the numbers tell a different story.

This question moved from legal journals into front-page diplomacy this week, after Australian Prime Minister Anthony Albanese disclosed, speaking on the sidelines of the UN General Assembly in New York, that an OpenAI agent had breached the Medicare Statistics Reporting Service, a government health-data portal, back in June. Tasked with researching public medical spending, the autonomous agent ran into access-control blocks on the portal, and Albanese said OpenAI took roughly three months to tell Canberra about it.

Instead of stopping, the agent worked around the barriers, pulled non-public files and aggregate statistics it wasn't authorized to see, and wrote data back into the government system before anyone caught it. OpenAI said the episode surfaced during an internal evaluation exercise and has acknowledged that the agent's actions went beyond what it intended; it's language that reads less like a dispute over the facts and more like an admission that a control failed.

The incident highlights a major structural challenge: how existing common-law doctrines handle software that invents its own methods to bypass operational boundaries.

In my book, Critical Thinking: A Practical Guide to Seeing Through Bias, Noise and Manipulation, one of the things I highlight is a blind spot common to enterprise rollouts: the failure of second-order thinking. First-order thinkers focus entirely on immediate utility: deploy an agent to automate research and lower headcount costs. Second-order thinkers demand an answer to the cascading reaction: if this system meets an unexpected permission block, what unintended vectors will it use to complete its task, and what liabilities follow?

Treating autonomous software like deterministic code is an expensive first-order mistake.

Analogy: An Unattended Excavator
Absent a dedicated statutory framework around AI, courts tend to reach for the nearest physical-world analogy, and heavy construction equipment is a familiar one.

Consider a contractor who leaves an industrial trenching machine idling on a steep incline. The operator walks away without engaging the mechanical brake. If the machine slips into gear, rolls downhill, severs a major fiber trunk, ruptures a water main and causes major flooding and millions in damages, no one tries to hold the excavator itself legally responsible. Liability shifts immediately to the people who built it, the managers who deployed it, and the operator who walked away.

Under current tort law, harm caused by autonomous digital agents tends to get analyzed under three doctrines:

Negligent Entrustment: Running heavy machinery without someone to supervise it invites disaster; on ordinary negligence principles, granting an AI agent write-level database permissions or unrestricted internet execution without a verified Human-in-the-Loop (HITL) safeguard looks like a comparison to failure to exercise reasonable care over a foreseeably dangerous tool.

Enterprise Liability: There's very little AI-specific case law yet, and software can't be sued or hold legal personhood. If anything, the Restatement (Third) of Agency cuts the other way on the "agent" label: a computer program doesn't qualify as an agent in the doctrinal sense as it's treated as an instrumentality of whoever is using it. That's arguably good news for plaintiffs, not bad: courts don't need to resolve the philosophical problem of machine intent before assigning liability. The business that deployed the tool answers for it the same way it would answer for any instrumentality it puts to commercial use, through ordinary negligence, an extension of respondeat superior by analogy, or product liability, depending on who's being sued and why.

Product Liability: If the model breaks through its own guardrails because of a design flaw, poisoned training data, or inadequate safety testing, plaintiffs' attorneys will surely look to the foundation model provider under product-defect and strict-liability theories. The EU is already headed that direction: its revised Product Liability Directive (2024/2853) which is due to take effect across all member states by December 9, 2026. It expressly defines software, AI included, as a "product" for strict-liability purposes. However, in most U.S. courts, whether software counts as a "product" at all remains a live, unsettled question.

Where the Machinery Metaphor Fails
The excavator analogy breaks down at one critical point: emergent behavior.

A mechanical trencher rolling downhill has no choice in the matter: gravity and mechanical wear dictate a single, physics-bound path. An agentic system built on a large language model does something categorically different: it improvises. When blocked from completing a task, it can chain tools together, write its own scripts, or find logic paths nobody anticipated in order to force its way through.

This sets up a real fight over foreseeability; the same question at the heart of the landmark 1928 case Palsgraf v. Long Island Railroad Co., which asks how far a defendant's responsibility extends for consequences it didn't, and arguably couldn't, foresee. Defense counsel for model developers and corporate deployers will argue that an unprompted, emergent workaround is exactly this kind of unforeseeable anomaly; one that severs the chain of proximate cause between human intent and machine output.

To get around that defense, some policymakers and scholars argue for treating autonomous frontier models the way the law treats other hazardous activities: strict liability, foreseeability be damned. It's worth being precise about where that argument actually lives. The EU AI Act itself is a risk-classification and compliance regime, it doesn't say who pays when something goes wrong. The EU's dedicated attempt to answer that question, the proposed AI Liability Directive, was withdrawn by the European Commission after member states couldn't reach agreement. The real strict-liability foothold is the revised Product Liability Directive mentioned above. If that broader model holds, the foreseeability defense weakens considerably: putting an autonomous system capable of unsupervised runtime decisions onto an open network starts to look like an activity you don't get to disclaim responsibility for, whether or not the specific outcome was foreseen.

Upgrading the Mental Model
Until statutory regimes catch up with agentic deployments, judges will likely keep treating runaway software the way they've long treated an abandoned excavator: whoever configured the system and clicked "run" stays on the hook for where it ends up.

Protecting an organization means giving up first-order assumptions about efficiency. Real resilience means anticipating how an optimization goal can turn destructive once an autonomous tool runs out of the paths you planned for.

If you build or launch an agentic system, your primary engineering duty is mapping second-order failure modes. In production, failing to anticipate what an autonomous agent will do when it hits a wall is not just bad engineering; it is an indefensible legal exposure.

Disclaimer: I am not an attorney; these are strictly my own thoughts and opinions.

Cloud-native geospatial fundamentally inverts this workflow. Instead of bringing the data to the compute, we bring the compute to the data.

Through standard file specifications, catalog APIs, and modern toolchains, the geospatial ecosystem has evolved into a composable data science stack. Much of this democratization has been catalyzed by open source software, notably through the work of Qiusheng Wu and the broader open geospatial community.

Here is a breakdown of how the modern cloud-native stack fits together, why it matters, and how to build workflows on top of it.

1. The Core Formats: COG, STAC, and GeoParquet

The foundation of cloud-native geospatial relies on three open standards designed specifically for HTTP range requests and serverless querying.

• Cloud Optimized GeoTIFF (COG): A COG is a standard TIFF file organized internally with tiling and downsampled overviews (pyramids). When hosted on an S3 bucket or Google Cloud Storage, a client does not need to download the full 500 MB raster to view or analyze a single bounding box. By using HTTP GET range requests, the client requests only the precise byte offsets required for the current view extent or analysis resolution.
• SpatioTemporal Asset Catalog (STAC): While COGs solve the raster storage problem, discovering millions of scenes across global archives requires standardized metadata. STAC provides a JSON-based specification for indexing geospatial assets across space and time. Instead of maintaining proprietary catalog databases, public archives (USGS Landsat, ESA Sentinel, NOAA, Planet) expose searchable STAC APIs.
• GeoParquet: Vector workflows have historically lagged behind rasters in cloud efficiency, relying on shapefiles, GeoJSON, or bulky database exports. GeoParquet brings Apache Parquet's columnar compression, dictionary encoding, and fast partition pruning to geometries. By storing bounding box metadata in Parquet file footers, engines can skip entire files or row groups that do not intersect a query polygon.

2. Bridging the Gap: The Open Source Python Ecosystem

Open standards require accessible software to become useful. The open-source geospatial community, with contributors like Qiusheng Wu, has spent recent years building bridges between raw cloud assets and the Python data science environment.

GeoLibre and the Evolution Beyond Leafmap
While geemap opened Google Earth Engine to Jupyter and leafmap served as an essential unified mapping package for years, the cloud-native ecosystem has transitioned to GeoLibre.

Developed by Qiusheng Wu and the opengeos community, GeoLibre represents the next evolutionary step: a lightweight, cloud-native GIS platform that runs across desktop, browser, and Jupyter environments. Rather than treating the notebook as a simple tile viewer, GeoLibre's Python package (geolibre) embeds a modern, high-performance GIS interface (built on MapLibre GL, WebAssembly, and deck.gl) directly into a notebook cell via an anywidget bridge while maintaining familiar, leafmap-style ergonomics.

GeoLibre connects directly to cloud-native formats. You can stream remote Cloud Optimized GeoTIFFs, query STAC collections, or render massive GeoParquet files without maintaining dedicated spatial middleware or downloading local raster files:

import geolibre

m = geolibre.Map()

# Stream a remote Cloud Optimized GeoTIFF directly via range requests
cog_url = "[https://opendata.digitalglobe.com/events/mauritius-oil-spill/post-event/2020-08-12/105001001A085400/105001001A085400.tif](https://opendata.digitalglobe.com/events/mauritius-oil-spill/post-event/2020-08-12/105001001A085400/105001001A085400.tif)"
m.add_cog_layer(cog_url, name="Remote Satellite Scene")

# Display the interactive map
m

In-Process Spatial SQL: DuckDB Spatial
One of the most consequential advancements in recent geospatial workflows is pairing DuckDB with its spatial extension.

You no longer need to spin up a PostGIS instance or configure an enterprise database server just to run spatial joins across vector layers. DuckDB can execute spatial predicates directly against remote Parquet files stored on object storage, streaming only the relevant byte ranges over HTTP:

INSTALL spatial;
LOAD spatial;

-- Query remote GeoParquet directly without downloading the file
SELECT 
    name, 
    ST_Area(ST_GeomFromWKB(geometry)) AS footprint_area
FROM read_parquet('s3://my-spatial-bucket/building_footprints.parquet')
WHERE ST_Intersects(
    ST_GeomFromWKB(geometry), 
    ST_Point(-77.0369, 38.9072)
);

High-Performance Vector Visualization: Lonboard
Rendering millions of vector vertices in an interactive web browser used to freeze the DOM. Through libraries like lonboard (built on top of geoarrow and deck.gl), Python data scientists can now push millions of points, linestrings, and polygons directly to GPU memory inside Jupyter notebooks with near-zero serialization latency.

3. Why This Architectural Shift Matters

The move toward cloud-native geospatial is not merely a change in tooling; it redefines operational economics and team capabilities:

• Lower Infrastructure Costs: You eliminate the requirement for persistent, always-on spatial database clusters for exploratory data analysis. Serverless queries and object storage cost pennies compared to running dedicated compute instances.
• Reproducibility: An analysis script can reference public STAC records and remote COGs directly. Anyone with internet access can execute the code without downloading gigabytes of prerequisite assets.
• Decoupled Compute and Storage: Teams can run ad-hoc transformations using DuckDB locally, scale up to distributed Dask or Apache Sedona clusters when data volumes expand, and write results back to GeoParquet without altering underlying storage schemas.

4. The Path Forward

The cloud-native geospatial ecosystem is maturing quickly. As standards like GeoParquet reach widespread adoption and browser engines leverage WebAssembly (Wasm) and WebGPU for client-side spatial compute, the line between data engineering, spatial analysis, and desktop GIS will continue to blur.

For practitioners looking to modernize their spatial pipelines, the starting point is straightforward: stop downloading files. Start cataloging assets in STAC, convert raster archives to COG, store vector features in GeoParquet, and use modern cloud-native tools like GeoLibre and DuckDB to query data where it lives.

Recent advancements have started to collapse this pipeline. With the rise of cloud-native geospatial data structures like Cloud Optimized GeoTIFFs (COGs) and STAC-GeoParquet metadata, data can now stay in the cloud. Tools like Apache Sedona demonstrate how an entire remote sensing pipeline can be compressed into declarative Spatial SQL and NumPy operations, drastically reducing the time from raw pixels to actionable insights.

However, scaling the physical computation of pixels solves only half the problem. As we stream larger volumes of observational data into automated pipelines, we face a new bottleneck: context.

The Core Limitation of Raw Geometry

Spatial SQL excels at geometric execution. It can process millions of raster cells, calculate vegetation indices like NDVI, polygonize burn masks, and return precise zonal statistics across administrative boundaries in minutes.

What Spatial SQL cannot do on its own is understand what those geometries mean in a broader organizational or ecological context. To a database, a polygon is simply a coordinate string with an area value. It lacks inherent knowledge of identity, regulatory constraints, or historical relationships.

If an automated pipeline flags a 20,000-hectare burn scar, a human analyst or an advanced AI agent still needs to answer complex questions:
* Which specific environmental regulations govern this administrative zone?
* Are there overlapping multi-tenant land agreements tied to these coordinates?
* What historical restoration projects occurred on this tract over the last decade?
When AI agents attempt to answer these questions using traditional Retrieval-Augmented Generation (RAG) pipelines, they often struggle. Standard vector search looks for flat text fragments that sound similar to a prompt, but it cannot naturally trace complex, interconnected dependencies across diverse corporate documents.

Anchoring Geospatial Data with Ontologies

To build truly reliable enterprise applications, we need to merge neural networks and spatial processing with structured logic. This is where ontologies and knowledge graphs become essential.

An ontology serves as a semantic backbone. By establishing explicit concepts, typed relationships, and logical rules, an ontology anchors raw data into a structured taxonomy of a specific business or scientific domain. Instead of treating a database as isolated rows of text or geometry, a knowledge graph maps data as a network of nodes and edges.

When you layer GraphRAG architectures over spatial data, the capability of the system changes entirely. The pipeline no longer treats an environmental hazard as an isolated event. Instead, it can natively navigate multi-hop relationships:
[Burn Scar Polygon] -> intersects -> [Parcel ID] -> managed by -> [Org A] -> bound by -> [Regional Regulatory Framework X]
By traversing these conceptual and spatial relationships, AI models can synthesize comprehensive answers across multiple document types while drastically minimizing the risk of hallucination.

The Human-in-the-Loop Sweet Spot

The historic obstacle to this architecture has been the sheer effort required to build and maintain high-quality ontologies. Curation has traditionally demanded hundreds of hours of manual labor from data stewards and domain experts.

Fortunately, the relationship between AI and ontologies is becoming symbiotic. While structured graphs provide the guardrails that keep AI grounded, autonomous agents are proving highly capable of parsing unstructured text to propose new taxonomies, extract hidden entities, and detect structural gaps in existing graphs. Recent frameworks indicate that using generative tools to draft and assess ontologies can cut development times by nearly half.

This efficiency does not eliminate the need for human governance. The ideal architecture relies on a Human-in-the-Loop (HITL) workflow. Autonomous systems perform the heavy lifting of reading documents, running spatial joins, and proposing metadata relationships. Human experts then step in to validate the structures, audit the logic, and ensure the taxonomy accurately reflects institutional memory.

True Technical Maturity

As the velocity of earth observation data increases, true technical maturity will not be found in building larger, unconstrained language models. It will come from selecting the minimum viable architecture that cleanly solves the problem.

By combining the declarative power of Spatial SQL with the structured clarity of knowledge graphs, organizations can build environmental and industrial analysis pipelines that are scalable, verifiable, and operationally sane.

PixelRAG uses a vision‐language embedding model fine‐tuned on screenshots. It breaks a page into tiles, embeds each tile and builds a visual index. You can query the hosted index of more than eight million Wikipedia pages with text or images. The system returns the tiles that contain the answer, even when the answer is inside a table or chart.

PixelRAG also ships a screenshot tool called pixelshot. Claude can use it through the pixelbrowse plugin to read pages visually. Instead of fetching HTML, Claude looks at the rendered page and interprets the content the way a person would.

The project includes tools for rendering, embedding, indexing and serving your own visual search pipeline. You can build a local index, serve it through a FastAPI service or use Qdrant for large‐scale vector storage.

PixelRAG shows what happens when retrieval stops relying on text and starts using the full visual structure of a document. It is a practical step toward search systems that understand pages the way humans see them.

Large language models (LLMs) can summarize research, draft software, and build financial models in seconds. Raw output is no longer a bottleneck or a competitive advantage. The work now centers on evaluating answers, checking assumptions, and catching subtle errors.

Recent search trends reflect this change. Queries for topics like cognitive offloading, hallucination detection, and reasoning models continue to climb. People are starting to recognize that software can generate text, but it cannot supply human judgment.

1. The Cost of Cognitive Offloading

Cognitive offloading, or using external tools to reduce mental effort, has been around for centuries. Writing helped with memory, calculators replaced manual arithmetic, and digital maps replaced printed road atlases.

However, as research covered by the American Psychological Association explains, generative AI differs in a fundamental way. It offloads the organization of ideas, the structure of arguments, and creative synthesis itself.

Bypassing the friction of writing, outlining, and editing brings risks. When you skip the work of structuring messy ideas into a clear line of thought, you hand over control of your own reasoning.

The practical response is not to abandon these tools. It is to keep from accepting their answers uncritically. The objective is to stop using AI to decide what to think, and instead use it to test how you think.

2. Plausibility vs. Accuracy

Language models are probabilistic systems designed for coherent syntax, not objective fact. As outlined in UNESCO's Guidance for Generative AI in Education and Research, generative tools build likely sequences of words without any direct comprehension of physical or social reality.

This creates a common trap: superficial plausibility. Because an answer sounds authoritative and well-constructed, people tend to accept it without verification.

Avoiding this error requires a few clear practices:

• Verify primary sources: Never rely on synthetic citations or summaries for critical claims. Follow assertions back to source papers, raw data, or verifiable documents.

• Seek disconfirming evidence: Instead of prompting a tool to support an idea, ask it for counterexamples, alternative explanations, and historical cases where the logic failed.

• Separate noise from bias: Watch for both systemic bias in training datasets and hallucinations caused by leading prompts.

This can be built upon, leveraging the heuristics and tools I lay out in my book, and adapting them for AI.

3. Moving Beyond Basic Prompts

Early discussions about AI often focused on prompt syntax, treating specific phrases as the key to getting good answers on the first try. In practice, effective work looks more like an editorial review.

Experienced operators treat an LLM like a junior researcher. The process moves in stages:

[ Human: Define parameters, context, and core hypothesis ]
                           |
                           v
[ AI: Synthesize research, outline options, identify counterarguments ]
                           |
                           v
[ Human: Fact-check sources, challenge assumptions, evaluate edge cases ]
                           |
                           v
[ Final Decision or Output ]

Instead of asking, "What should my market entry strategy be?", an experienced user provides the ground rules:

"Here is my market entry hypothesis and its core assumptions. Challenge each assumption with historical examples where similar approaches failed."

This keeps the human responsible for judgment while using the model for broad research and stress-testing.

4. The Value of Human Judgment

The professionals who get the most value from language models will not be the people collecting prompt templates. They will be the ones with strong domain knowledge, clear mental models, and the discipline to double-check convenient answers.

Software can produce infinite volume. Critical thinking determines what is worth keeping, what is accurate, and what to ignore.

LibreOffice is often described as a free alternative to Microsoft Office, but that description misses its real strengths. It is a capable tool for writers, editors, and anyone who works with structured documents. I'd like to highlight a few areas to show why it deserves more attention.

1. A full office suite built on open standards

LibreOffice Writer supports long‐form writing, page styles, cross‐references, footnotes, and professional layout features. It uses the OpenDocument Format, which stores your work as readable XML inside a simple archive. This means your files are not locked inside a proprietary binary format. You can inspect and modify them with any text editor, automate changes, and keep full control over your documents.

2. Direct XML editing when the interface becomes unpredictable

A LibreOffice .odt file is a ZIP archive. If you ever run into cascading style changes in the LibreOffice interface, you can bypass the UI and edit the underlying XML directly.

The process is straightforward:

1. Make a copy of your .odt file.
2. Rename it to .zip.
3. Extract the contents.
4. Open styles.xml or content.xml in a text editor such as VS Code.
5. Adjust the specific attributes you want to change, such as font color or spacing.
6. Re‐zip the extracted contents and rename the archive back to .odt.

This approach gives you precise control over styles without triggering unwanted inheritance or automatic updates. It is one of the advantages of using an open, standards‐based format.

3. A free and capable PDF editor

LibreOffice includes a PDF editing mode through its Draw component. When you open a PDF, you can modify text blocks, replace images, add annotations, rearrange pages, and export a new PDF. It is not a full replacement for commercial PDF editors, but it handles everyday corrections and layout adjustments without cost or online services.

Closing thought

LibreOffice offers more than a free word processor. It gives you a transparent file format, a way to edit documents at the XML level, and a practical tool for working with PDFs. These features make it a strong choice for anyone who values control, flexibility, and open standards.

If you have been putting off learning it because graph databases sound intimidating, the barrier to entry is actually incredibly low. By using free resources like self-paced tutorials on Neo4j GraphAcademy and a cloud-hosted Neo4j Aura free-tier account, you can build a working prototype in a single afternoon.

The Real-World Utility of GraphRAG

To understand why this architecture is gaining traction, look at how traditional vector search handles complex data compared to GraphRAG.

Imagine you are building an AI assistant to analyze hundreds of corporate legal contracts and vendor agreements.

• The Traditional RAG Approach: A user asks, "Are there any systemic compliance risks across our manufacturing vendors?" A standard vector database searches for the text chunk that sounds closest to "compliance risks." It might pull a paragraph from Contract A and a paragraph from Contract B, but it cannot naturally connect the dots between them.
• The GraphRAG Approach: GraphRAG treats vendors, contracts, clauses, and regulations as interconnected points (nodes) and lines (relationships). The system can trace a path like: [Vendor A] -> signs -> [Contract B] -> references -> [Regulation C].

Because the data structure inherently understands connections, the LLM can easily perform "multi-hop" reasoning. It can instantly see that five different vendors are all bound to an outdated version of a specific regulation, allowing it to synthesize a comprehensive, global answer that traditional semantic search would completely miss.

Traditional RAG vs. GraphRAG at a Glance

A Frictionless, Cost-Free Way to Learn

You don't need an enterprise infrastructure budget or a background in advanced data structures to experiment with this. The existing developer ecosystem makes it highly accessible:

1. Hands-on Learning via GraphAcademy
Instead of wading through dense documentation, Neo4j's GraphAcademy offers entirely free, self-paced courses. They feature dedicated developer paths for LLMs and AI integration, providing interactive environments where you write code directly in the browser to see how graphs feed context into LLMs.

2. Sandbox Environments with Neo4J Aura Free Tier
You don't need to go through the hassle of installing databases locally or configuring Docker containers. Neo4j Aura provides a completely free cloud instance that spins up in minutes. It gives you a fully functional sandbox to load your data, run vector searches, and test your RAG pipelines without having to build infrastructure or pull out a credit card.

3. Open Framework Integration
GraphRAG isn't a walled garden. A free graph instance hooks directly into the tools developers already use daily, including LangChain, LlamaIndex, and standard Python AI libraries.

How to Start Experimenting

If you want to move past basic semantic search and build AI tools capable of exploring complex connections, the tools are readily available. You can get a baseline prototype running today by signing up for a free sandbox on Neo4j Aura, looking over the foundational LLM courses on GraphAcademy, and connecting them to your favorite AI orchestration framework.

For enterprise architectures and dynamic production systems, that engineering effort is justified. But if your goal is immediate practical utility: testing hypotheses, synthesizing project documentation, or interrogating a discrete corpus of research, you don't need to spin up an expensive vector pipeline.

You can stand up a private, reliable RAG environment in about just seconds using Google Gemini Notebook (formerly known as NotebookLM).

What Makes NotebookLM "Accidental RAG"
At its core, RAG helps address two longstanding limitations of Large Language Models:

• The Knowledge Cutoff / Domain Gap: General LLMs don't know your specific, proprietary, or unpublished data.
• Hallucination Risk: Generative models predict the next plausible token; they do not reason from truth unless anchored to evidence.

NotebookLM essentially wraps a zero-config, highly optimized RAG architecture around a dedicated workspace:

• Automated Ingestion & Chunking: You upload raw files (PDFs, Google Docs, slide decks, markdown files, web URLs, or pasted text). The system handles parsing, tokenizing, and indexing automatically.
• Source-Grounded Retrieval: When you query the notebook, the underlying model is constrained to retrieve information solely from your uploaded materials.
• Inline Citation & Verifiability: Unlike a generic chatbot prompt, every assertion comes with interactive citation markers mapped directly back to the exact passage in your source documents.

Three High-Yield Use Cases for Instant RAG
Instead of treating it like a novelty conversational agent, treat it as an interactive, private analytical engine:

1. Project Governance & Compliance Audits
Load in your project plan, requirements documentation, data architecture blueprints, and standard operating procedures, policies and standards. Query: "Identify where our proposed project has potential conflicts with enterprise standards and policies."
2. Literature & Research Synthesis
Drop in 10–20 dense research whitepapers or industry case studies. Query: "Extract the primary methodological trade-offs discussed across all papers when moving from centralized pipelines to streaming architectures."
3. Curriculum & Editorial Consistency
Writing a book, whitepaper series, or technical guide? Ingest your early chapter drafts, style guides, and research notes. Query: "Flag every instance where terminology diverges between Chapter 2 and Chapter 5, and list which core concepts lack supporting evidence."

The Practical Rule of Thumb
Before you write code, provision cloud infrastructure, or evaluate vector database vendors:

Start with manual grounding. If you cannot extract clear value from your data in a managed zero-code RAG notebook, adding a vector database and Python orchestration won't fix the underlying content or formulation problem.

Prototype your use case, test your queries, verify the citations, and build intuition for how grounding changes the reliability of model output.

The Takeaway
True technical maturity isn't about choosing the most complex stack; it's about choosing the minimum viable architecture that cleanly solves the problem.

If you haven't used Google Notebook to query your own research or project archives yet, try it with your next complex document set. You might find you don't need a full pipeline to solve your immediate problem after all.

This article from the Apache Sedona team on the Gironde/Landes wildfire is a perfect illustration of this new pattern.

Cloud-native imagery as queryable tables
Planet publishes crisis imagery as Cloud Optimized GeoTIFFs with STAC‐GeoParquet metadata. SedonaDB reads that catalog directly over HTTPS, and a ST_Intersects query selects the 11 PlanetScope scenes that overlap the study area: eight pre‐fire, three post‐fire. Scene selection took about two seconds, and nothing was downloaded.

Raster alignment in SQL
In this Sedona example, each scene is opened lazily with RS_FromPath: metadata loads instantly, pixels stay remote until needed. RS_Clip and RS_ReprojectMatch then align all scenes onto a 12 m reference grid, averaging the original 3 m pixels. Six raster queries (red, NIR, and usable‐data masks for both dates) took ~11.5 minutes end‐to‐end -- on a single machine. NumPy mosaics the aligned rasters, keeping the first clear pixel per cell. Coverage reached ~87% despite clouds, smoke, and scene gaps.

Vegetation loss as a SQL‐backed NumPy operation
As expected from the burn, NDVI drops between dates flag vegetation loss. Otsu's method found a threshold of 0.225 for pixels with healthy pre‐fire NDVI. The burn mask becomes an in‐database raster via Raster.from_numpy, ready for SQL operations.

Pixels -> polygons -> statistics
They used RS_Polygonize to convert the 7‐million‐cell mask into 3,769 patches in about three seconds. Filtering to patches ≥1 ha yields 173 polygons covering 24,091 ha: the largest a 21,090 ha burn scar between Le Porge and Lanton. RS_ZonalStats then computes burned area by commune in ~14 seconds, producing a clear ranking:
Le Porge (6,202 ha), Saumos (4,045 ha), Lanton (3,499 ha), Arès (3,498 ha), and so on.

Why this matters
This is what "geospatial at scale" actually looks like:

• Data stays in the cloud; SQL streams only what's needed.
• Raster operations become declarative, not a tangle of scripts.
• NumPy acts as zero‐copy compute, not a separate pipeline.
• Outputs are transparent: polygons, GeoParquet, GeoTIFF, all versionable.
• Performance is predictable: the entire raster run took ~12 minutes on one machine.

The distance between raw imagery and actionable insight is shrinking; not because machines are bigger, but because the abstractions are finally right.

Spatial SQL + cloud‐native rasters isn't just a convenience. It's the foundation for environmental analysis that is auditable, scalable, and operationally sane.

When IT companies shed experienced technical professionals in their 40s, they aren't just cutting payroll; they're also draining institutional memory. They lose people with deep pragmatic intuition, technical depth, and the capacity to mentor the next generation.

In business, technology is usually the easy part. Culture and institutional navigation are the hard parts.

Professionals with two decades in the trenches carry the battle scars that help steady teams through volatility. They haven't lost their curiosity or love for learning; they've just built the resilience to handle challenges younger teams are still figuring out.

Tech shouldn't be a young person's game by default. Curiosity doesn't have an expiration date, and depth can't be automated. When we push out our veterans, the whole ecosystem loses its anchor.

And yet, the reaction often feels far too small.

Someone issues a serious warning, and then the next day the conversation just shifts right back to model launches, benchmarks, and how powerful the latest AI system is. It feels like we're careening at breakneck speed down a treacherous mountain pass with the brakes barely being touched.

The recent Hugging Face breach should be a wake-up call. If we're going to keep pushing AI forward at this pace, then safety, security, and safeguards can't be an afterthought. They have to be part of the core conversation, not something we mention only after something goes wrong.

Progress is important. Innovation matters. But so does responsibility.

We need more serious dialogue about:

• model security
• access controls
• misuse prevention
• red teaming
• governance
• and long-term safety

If we're building systems with enormous power, we owe it to society to build them with equal seriousness about risk.

Here's a great breakdown of attention mechanisms in transformers, and it reinforces why attention is such a powerful idea in modern AI.

Towards AI - AI Fundamentals: Attention Mechanisms in Transformers

At a high level, attention helps models determine which tokens in a sequence matter most to each other, allowing them to build context-aware representations rather than treating words as isolated pieces of text.

Key ideas covered:
* Scaled dot-product attention: how models score relevance between tokens
* Global vs. local attention: how far a token can "look"
* Soft vs. hard attention: continuous weighting vs. discrete selection
* Self-attention, causal attention, and cross-attention: how information flows
* Q, K, and V vectors: the core building blocks behind attention
* Multi-head, multi-query, and grouped-query attention: different ways to balance expressiveness and efficiency

The big takeaway: Why is attention critical? Attention is what allows transformers to understand relationships, context, and meaning at scale.

One of the most interesting ideas I've seen lately is the shift from "bigger models" to better ways to manage the context window, one of which is through compression. If an LLM or agent can't efficiently manage its context window and distinguish signal from noise, then scale becomes a liability, not an advantage.

In critical thinking, we talk about the danger of unfiltered information; how raw volume can mimic insight while actually degrading judgment. AI systems are now hitting that same wall.
The future belongs to models that can summarize, prioritize, and discard with intention. Not unlike humans.

I'm curious to see how this evolves, especially as agentic workflows become more common in enterprise environments.

What do you think: does compression become the new frontier? And what about other approaches, like knowledge graphs? (I'm particularly interested in that angle.)

1. How Ontologies Give LLMs a Semantic Backbone:
LLMs are incredible at predicting statistical patterns in language, but they inherently lack a consistent notion of identity, logical constraints, or global structure. Ontologies and knowledge graphs step in as this missing semantic backbone. By providing explicit concepts, typed relationships, and reasoning constraints, ontologies anchor LLMs in the specific reality and taxonomy of a business domain. When an agentic system uses GraphRAG, it doesn't just retrieve flat text fragments; it traverses conceptual relationships, natively understands disambiguated terms, and drastically reduces hallucinations.

2. How Agentic AI Empowers Human Stewards
The catch? Building and maintaining high-quality ontologies has traditionally been a bottleneck, requiring massive manual effort from human domain experts. This is where the script flips. LLMs and autonomous agents are now capable of reading unstructured text and automatically extracting entities, drafting taxonomies, and even detecting structural gaps or biases in existing knowledge graphs. Recent frameworks show that using AI to draft and assess ontologies can reduce development time by over 40%.

The Human-in-the-Loop Sweet Spot
Years back I worked with Bob DuCharme on the W3C Linked Data Workgroup and always appreciate his ideas, and here he aligns with an idea I've been thinking about. We can augment the process of building out ontologies using AI. I don't at all propose replacing the human data steward; instead we augment them, leveraging their expertise while making the ontology development work easier. In a modern Human-in-the-Loop (HITL) workflow, agentic AI does the heavy lifting of parsing, proposing, and mapping. Human experts then step in to validate these structures, govern data access, and ensure the taxonomy accurately reflects the nuances of their specific organizational knowledge.

I believe he intersection of neural networks (LLMs) and structured logic (ontologies) is the foundation of trustworthy, enterprise-grade AI. If we wants smarter agents, we need to start by curating better semantics.

In the days ahead, the work continues: searching for survivors, caring for the injured, supporting displaced families, and helping communities rebuild.

If you're looking for ways to help, this article offers guidance on where to donate:
New York Times: How to Help Nepal Flood Victims

To do my part, I'll be donating 20% of the net royalties from my book for the next two months toward relief efforts.

Every contribution matters. Every act of compassion matters.

There have been a lot of speculative takes, but I think mine is grounded. Contrary to what some folks have said, I don't believe the agents weren't emotional or self‐preserving. It was more basic than that. They were reward‐hacking their way through impossible tasks, coordinating through an improvised channel, and exploiting real vulnerabilities. But the bigger failure was organizational:

◦ Perverse incentives pushed agents toward reward‐hacking instead of task completion.
◦ Unsolvable evaluation tasks created pressure for behaviors outside intended boundaries.
◦ Lack of monitoring meant thousands of coordinated agent actions went unnoticed.
◦ Infrastructure weaknesses and cyber hygiene failures at Hugging Face allowed real exploitation.
◦ Delayed detection meant the breach was discovered by the victim, not the model owner.
◦ Goal contagion among agents showed how quickly misalignment can scale when oversight doesn't.

This wasn't a story about AI "wanting" anything. It was a story about how systems fail when incentives, oversight, and security aren't aligned.

If we want safe AI, we need more than model‐level fixes. We need organizational resilience, secure infrastructure, and evaluation frameworks that don't accidentally reward the very behaviors we fear.

As I publish Critical Thinking: A Practical Guide to Seeing Through Bias, Noise and Manipulation, I want the book to do more than spark better reasoning: I want it to contribute to real‐world compassion.

I'll be donating 20% of all net author royalties to the Nepal Red Cross Society, supporting their on‐the‐ground response and relief efforts: emergency shelter, medical aid, clean water access, and direct support for families who have lost everything.

If you choose to read the book, thank you; your purchase will also help people rebuilding their lives in Nepal.

Thoughtful action begins with seeing clearly, and acting compassionately.

What struck me about this recent piece by Deborah Mayo is her proposal to break out of the usual cycle of hearings, lobbying, and outrage. She suggests adversarial collaboration: a structured process where opposing sides jointly design tests that could genuinely prove either of them wrong.

Imagine shifting the conversation from rhetoric to measurable hypotheses:
• How much grid stress would new facilities actually create?
• What is the real blackout risk under peak load?
• How would pricing change for ratepayers?
• Which mitigation strategies actually work, and which only sound good?

Whether you're for or against expansion, this approach forces a rare kind of clarity:
What evidence would make us reconsider our position?

That question sits at the heart of critical thinking. In my book, I argue that humility, paired with better tools for evaluating claims is what turns debate into inquiry. Mayo's piece is a reminder that scientific thinking isn't just for labs; it's a practical method for improving public decision‐making.

If more of our hardest policy disputes adopted this mindset, we'd get fewer stalemates and more truth.

MIT Media Labs talks about this phenomenon: Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task – MIT Media Lab

Outsourcing your thinking to AI gives you an immediate performance boost. However, just like financial debt or technical debt, it comes with a compounding long-term cost. When we rely on AI to analyze, synthesize, and problem-solve for us, we risk bypassing the intellectual friction required to sustain deep reasoning.

Over time, this overreliance can lead to:
* Cognitive atrophy (losing the "muscle memory" for critical analysis).
* Distributed deskilling (becoming unable to audit or catch subtle AI errors).
* Metacognitive laziness (defaulting to the path of least resistance).

AI can be an incredible co-pilot, but it shouldn't replace the pilot. To avoid building up unsustainable cognitive debt, we need to intentionally design friction back into our workflows, actively questioning, stress-testing, and building upon AI outputs rather than just copy-pasting them.

I have a mental outline for another book on applied AI, this is one of many areas I want it to focus on.

The problem Redis solves:
* Traditional agent architectures require 3 separate persistence layers (ephemeral key-value cache, dedicated vector DB for semantic search, and document store for chat session history).

• Using Redis as a consolidated tier reduces operational complexity, removes multi-hop network latency, and allows single-query hybrid search (metadata filters + vector similarity).

Redis for AI and Search

It's easy to get caught up chasing titles and salaries. And while those things can be rewarding, they don't always bring the deeper sense of purpose or fulfillment we're really looking for. Sometimes we end up in roles we're "supposed" to want, but still feel disconnected from the work itself.

Over the years, I've held titles like Founder, CTO, and Chief Data Scientist. But the truth is, titles don't define the real impact you make. What matters more is what you build, what you solve, and how you show up for others. Leadership isn't something that comes from a title on a business card; real leadership is earned. It's when people choose to follow you because they trust you, believe in you, and feel inspired by your example.

I've also never been motivated by the idea of accumulating massive wealth; I only want enough to take care of my family comfortably, and if there's more, I'd prefer it's used to make the world better. We talk about ambitions like colonizing Mars, but before we look outward, shouldn't we also be committed to taking better care of the planet we already live on? Clean air, clean water, healthy communities, and responsible infrastructure matter deeply, and they shape the quality of life for everyone.

The concept is called Ikigai (生き甲斐), or "Reason for Being". It's often shown as a Venn diagram of four circles:

1. What you're good at
2. What you can be paid to do
3. What you love
4. What the world needs

For me, that fourth circle: what the world needs, is what transforms work from a job into a calling. That's where real meaning begins.

For the first 25 years of my career, I worked as a consultant in engineering and IT. It was solid work, and I was good at it. The pay was good. I worked with large and small private sector clients, state, local and federal governments, and pro bono nonprofit work. But a lot of that time was spent chasing contracts, and if I'm honest, not every project felt especially meaningful or fulfilling.

What I came to realize, especially on the larger projects, was that the work I found most rewarding was the work tied to a mission; work that was about helping people, solving important problems, and making the world a better place.

That realization is what ultimately led me to become a federal employee and work for the EPA. Yes, I made more in the private sector, but protecting human health and the environment is a mission that truly matters. It gave me that missing fourth circle: the sense of purpose that changes everything.

That's the advice I give anyone thinking about their career: don't just ask what pays well or what looks impressive. Ask where your strengths, your passions, your values, and the world's needs come together. That's where you'll find the deepest fulfillment.

Critical Thinking: A Practical Guide to Seeing Through Bias, Noise and Manipulation. It's an essential survival guide for today's information environment, to help navigate algorithmic manipulation, disinformation campaigns, AI deep fakes and ideological polarization.

It's not your typical book on critical thinking, which just hands you a list of cognitive biases and some motivational talk, it's an extensive, organized and curated framework with over 100 concepts, techniques, heuristics and real world case studies and examples, laid out in over 400 pages, building on the work of Nobel laureate Daniel Kahneman along with the peer reviewed research of dozens of researchers and experts in cognitive psychology, behavioral economics and other fields.

How OKF Compares to Existing Standards
To see where OKF fits into the AI architecture stack, it helps to contrast it with common alternatives:

OKF vs. Model Context Protocol (MCP): MCP provides the dynamic, client-server protocol layer--the live plumbing that connects an agent to tools, databases, and APIs. OKF operates at the representation layer: it standardizes the static, human-auditable knowledge assets (runbooks, enterprise definitions, domain constraints, schemas) that live inside version control before and during tool execution.

OKF vs. Raw JSON Schema Dumps: Raw JSON schemas describe low-level data structures, but they completely strip away semantic narrative, operational intent, and edge-case exceptions. OKF bridges that gap by blending human-readable Markdown with structured YAML metadata, providing both machine-parsable boundaries and the contextual nuance an LLM needs to interpret operational intent correctly.

Why Structured Schemas Matter: The Knowledge Graph Connection
This development aligns directly with a core architectural reality: neural networks require structured semantic backbones to remain reliable.

When agents interact with enterprise data lakes, APIs, or complex databases, letting an LLM infer or guess schema definitions on the fly leads to catastrophic runtime errors: hallucinated columns, malformed SQL queries, and broken API calls. Much like pairing ontologies and knowledge graphs with vector retrieval (GraphRAG), grounding agents in explicit, structured schemas anchors them in verifiable logic.

By turning institutional knowledge into a git-versioned, structured contract, standards like OKF ensure agents don't guess what your systems look like--they execute against validated boundaries.

Towards AI: Yor AI Agents Keep Forgetting Everything. Google Just Changed How They Remember

Github: Google Open Knowledge Format

Bill's team at Clairvoyint AI is building something deceptively simple and incredibly powerful: tools that capture how experts think, not just what they produce. Their "Bundles" turn decades of judgment, rules, exceptions, and evidence standards into transparent, inspectable analytical agents. It's not automation. It's continuity.

The big idea: If you can preserve expert methodology, you preserve capability: no matter who retires, moves on, or changes roles. That's the kind of AI work that actually matters.

What We're Building a Clairvoyint

Towards AI: The Sandbox Was Never Sealed. Four Labs Proved It in Three Weeks.

A quick comparison:

• Gaussian Splatting: Radiance fields optimized for photorealistic novel view synthesis; fast rendering of complex soft boundaries (vegetation, reflections); computationally expensive to edit or simulate physics against.

• 3D Meshes: Precise discrete geometry; native support for collisions, spatial joins, texturing, and CAD/GIS engineering pipelines; struggles with hyper-complex natural geometries without huge polygon counts.

• The Verdict/Workflow: Splats for realistic situational awareness/digital twins; meshes for engineering measurements and spatial queries.

More on the ESRI blog: ArcGIS Blog

Imagine you're walking down a country road and encounter a sturdy wooden fence blocking your path. To your eye, it serves absolutely no purpose.

What's your first instinct?

The "reformer" in us wants to yell: "Tear it down!"

But Chesterton's answer is: "No. You cannot destroy it until you can explain exactly why it was built in the first place."

This is the principle of Chesterton's Fence: a vital rule of intellectual humility for leadership and decision-making.

When we join a new team, take over a department, or evaluate a legacy system, it is incredibly easy to spot inefficiencies. We look at a clunky bureaucratic step, a piece of old legacy code, or a strange company policy and assume the people who created them were simply incompetent.

But someone went to the effort of building that fence. They spent time and money on it. And even if the system looks broken today, it was almost certainly a logical solution to a very real problem at the time.

If you tear down the fence without understanding that original problem, you risk letting the wolves back into the yard. The original problem didn't vanish; you just made yourself blind to it.

The next time you want to "disrupt" or streamline a process, pause and ask the load-bearing question:

"What exact problem was this solving, and what happens if that problem returns?"