The whole stack, in one page.

HTML names the parts. CSS decides how they look. JavaScript reacts when someone interacts. An API moves data between systems. Python automates and analyzes behind the scenes. GitHub stores the history, Vercel publishes the URL, Supabase remembers data between visits.

That is the entire mental model. Every tool on this site is one of those jobs wearing a different name. When something breaks, ask which layer owns the problem: structure, style, behavior, data, or deployment.

<button>Show open shelters</button>      <!-- HTML: the part exists -->
button { background: crimson; }          /* CSS: it looks pressable */
button.addEventListener("click", load);  // JS: something happens
fetch("https://api.weather.gov/alerts")  // API: data arrives

Skip ahead: the rest of this tab is not prose. It is working tools. Section 1 runs live SQL against a real Red Cross Parquet file in this page. Section 4 is a searchable browser of all 1,497 Calcite icons. Start there.

Parquet is useful only if it disappears behind a better Red Cross question.

Esri's June 2026 ArcGIS Online update introduced Parquet feature layers in beta. The idea is simple: keep large, read-only spatial data in a columnar format so web maps can draw and filter it faster.

That does not automatically make it useful day to day. The useful version is a tool that answers questions like where do risk, hardship, population, and Red Cross operating geography overlap? Parquet is just the fast read path underneath.

The live demo below uses Red Cross canonical data from data.jbf.com. DuckDB-WASM runs SQL against the public county Parquet file inside this browser page. No iframe, no server-side database, no staged screenshot.

Loading query...

Honest answer: do not sell this as a new everyday ArcGIS workflow yet. Sell it as proof that a governed Red Cross data spine can power fast question-answering tools without creating another source of truth.

The spectacular demo is not "look, a file." It is "show me where risk and need collide."

The public-safe Red Cross data spine already has enough to tell a strong operational story: geography, chapter hierarchy, population, household hardship, social vulnerability, natural hazard risk, FEMA disaster history, and ZIP/tract lookup context.

That means the peer demo should ask a human question first, then reveal that Parquet makes the answer fast and portable.

Recommendation: keep the live iframe as the technical proof, but frame the story as a Red Cross risk radar. The impressive part is not that Parquet exists; it is that one governed data spine can answer a real operations need in seconds.

The beta limitations do not kill the idea. They define where it belongs.

ArcGIS Parquet feature layers are promising, but the June 2026 beta is not a drop-in replacement for every hosted feature layer. Treat it as a high-performance read-only reference surface, not as the operational edit layer for live incident work.

Verdict: worthwhile, but not universal. For Red Cross, this is excellent for big canonical read-only geography and analytics surfaces. It is not the right storage layer for editable operational workflows, offline response, or private sensitive data that has not passed source-owner and suppression gates.

Calcite is the design system the SDK ships with — including 1,497 icons.

When you build a custom app on the ArcGIS Maps SDK, you also get Calcite: Esri's open-source component and icon system. This is a live reference for every icon in @esri/calcite-ui-icons v4.5.0, grouped by category, with a curated hall of fame and click-to-copy markup.

Click any icon to copy its full <calcite-icon icon="…"></calcite-icon> tag — ready to paste into an app, or into another AI conversation where it self-labels as a Calcite icon.

Beginner rule: if you are building on the SDK, reach for a Calcite icon by name before drawing your own — the set is huge and already on-brand.

Build, store, publish, and remember.

Git and GitHub track your project history. Vercel publishes the project to the web. Supabase gives an app a database, login system, storage, authorization rules, and backend-like services when a static page is no longer enough. These are not the same thing, but they often sit next to each other in one real project.

• Git is the version tracking tool on your machine.
• GitHub is where the tracked project can live online.
• Vercel is where the project can become a public URL.
• Supabase is where an app can keep structured data, user identity, file storage, and authorization rules.

See it live, not abstract: Codex 101's working-set panel shows this repo's actual GitHub remote, Vercel URL, and branch instead of a generic diagram.

Use these when something should not disappear into chat.

Some instructions are meant to be shortcuts. They save you from re-explaining the whole checklist every time you want a useful pattern preserved.

Promote this to a standard.

Run a standards sweep.

Plain version: say Promote this to a standard for one excellent thing, and Run a standards sweep when you want the agent to find the reusable things you have already built.

Five Rust-built tools, tested in a real repo, on real Red Cross data.

2026's Python tooling wave is Rust underneath: uv, Ruff, Polars, and DuckDB are all Rust engines wearing a Python interface, and marimo is the notebook that fixes what made Jupyter fragile. Instead of describing them, they were installed, benchmarked, and run against the real 3,153-county Red Cross canonical table in a standalone lab repo.

Demo 1: Polars vs pandas, same questions, 5 million rows

Identical read/groupby/filter work, run three times each, best time kept. Correctness came first: a 1,000-row self-check asserted both libraries computed the exact same per-group totals before any speed number counted.

CSV parsing is the blowout, Polars' multithreaded Rust reader against pandas' single thread. Parquet read is close for both, because Parquet already does the hard work; the format matters more than the library there.

Demo 2: DuckDB, real Red Cross data, zero import step

DuckDB queried the canonical county_master table directly from its CSV, the same 3,153 FIPS-keyed counties used across Red Cross apps. No database server, no load step. Grouped on the code, displayed the name, same rule as every other Red Cross tool.

Divisions by ALICE-below-threshold households (rollup on DCODE)
  Southwest and Rocky Mountain Division   875 counties   11,624,684
  Southeast and Caribbean Division       621 counties   11,472,668
  Northeast Division                     218 counties    9,720,723
  Pacific Division                       273 counties    9,118,770
  North Central Division                 741 counties    7,161,864
  Central Atlantic Division              425 counties    5,424,175

The rollup wrote straight to Parquet and read back, still no server. A self-check confirmed the six-division sum matched the raw column sum exactly: 54,522,884 households, no rows dropped in the GROUP BY.

Demo 3: marimo, a reactive notebook that is a git-diffable file

Same county data, wrapped in a notebook with a division dropdown. Picking a division reruns the summary stats and county table automatically. There is no "Run All," and no stale cell holding yesterday's answer. The whole notebook is one plain .py file, so it reviews and diffs like normal source code instead of a JSON blob.

All three demos, their generator scripts, and the self-checks that prove them live in the standalone research repo, kept separate from this teaching site so experiments never risk the deployed build.

Plain version: these numbers are real terminal output from this machine, reproducible with uv run and no manual setup. Every claim here has a repo behind it.

Words that stop sounding mysterious.

Search a term, or scroll the list. The definitions stay plain on purpose. This is vocabulary for getting oriented, not documentation for experts.

The second pass can get more technical.

These ideas matter, but they should not interrupt the first beginner path. Keep them here until the foundation is comfortable.

File access only matters if the loop closes.

The point is not that Codex can edit files. The point is that it can make a scoped change, verify it, and leave behind a clean trail.

Plain version: chat gives advice. A project agent can do the work in the project and show the evidence.

A skill is a reusable workflow recipe.

A skill should raise the floor. It should not give permission to make a louder bad page.

This page is the example: the skill is only useful when it improves the project workflow and leaves proof behind.

Five capabilities, one sentence each.

Everything past the repo loop is one of these. None of them need a chapter.

Start with concrete tasks.

Codex makes the most sense when the request has a real folder, a visible target, or a clear output. These prompts are intentionally practical.

In my Downloads folder, find the receipts I need to process. Analyze them into an Excel workbook, categorize each transaction, and add charts that show spending patterns.

From now on, when I ask for a learning page and do not specify the format, use this left-rail guide layout with short sections, practical examples, and a table of contents.

Open the local app in the browser. Test the buttons, navigation, mobile layout, and the main success path. Fix any visible issues you find.

Three labs to try first.

Small enough to finish, real enough to show why Codex is different.

Deeper Codex topics belong in a second pass.

The first pass should stay practical. These topics are useful after the basic agent loop makes sense.

A plain-English prompt becomes a live ArcGIS map.

This tab uses the Lower 48 choropleth app as a concrete bridge between Coding 101 and real GIS work.

The important idea is not that the app is complicated. The important idea is that one prompt turned into a real web interface with controls, map layers, live services, and deployment.

Beginner frame: this is what coding looks like when HTML, CSS, JavaScript, APIs, ArcGIS, and deployment all show up in one small project.

The request described the user experience first.

The prompt did not start with library names or architecture. It started with what a person should be able to do: see the 48 states, choose variables, search, zoom, change basemaps, and click a state for a useful summary.

make me an app showing the 48 state and then allow me to select different variables and you color code the states choropleth style and also give me searchable drop down of states so when I select a state it zooms to the state and a hope button to return and a button to allow various base maps and some simple instrcutions and an email to jbf@jbf.com if questions and when a user clicks on a state give me a pop up with few facts and 30 word overview
add live NWS alerts and current IRWIN wildfires

Useful habit: describe the workflow in plain English before worrying about the code. The code should serve the workflow.

The working demo stays inside the lesson.

The embedded app keeps its own Prompt and Output tabs. Click Output inside the frame to use the map, change variables, search for a state, switch basemaps, and test the live overlays.

Deeper map topics belong after the first pass.

The intro should stay focused on what the app does. These topics are valuable once the visible workflow makes sense.

Stop treating search as a tool call. Let the agent write a search program.

Search as Code (SaC) gives the model low-level retrieval primitives and lets it compose them into one small program — then run it — instead of asking for information one question at a time.

This is the same shift Codex 101 describes for project work, pointed at information retrieval. An LLM already writes code well, so code becomes a cleaner control language than a back-and-forth chain of tool calls.

One line: search becomes programmable infrastructure for agents, not a webpage for humans.

One program beats a chain of tool calls.

The traditional agent asks for information one step at a time: search, wait, read, search again, wait, read again. Every step is a round trip, and raw results pile up in the conversation.

# Old way — a chat loop, one question at a time
search("fires in CA")
search("evacuation orders")
search("shelter capacity")
# ...then reason over whatever came back

# New way — the model writes and runs one program
results = parallel_search(["fires in CA", "evac orders", "shelter capacity"])
clean   = dedupe(results)
top     = rerank(clean)
answer  = aggregate(top)

Why it is faster: parallel instead of sequential, loops and ranking handled in code instead of across twenty chat turns, and a clean context because only the answer comes back.

Same question, two engines, in real time.

Pick a question and press run. The left engine asks one thing at a time and waits for each answer. The right engine writes one program and fires every search at once. Watch the clocks.

The speed is the visible part, not the point. What actually changed: the AI wrote and ran the whole workflow instead of asking one question at a time. Why that matters is section 4.

"Which 3 Florida counties have the highest flood risk right now?"

The tool-call way takes a dozen turns: list counties, search NOAA county by county, search FEMA, compare by hand. Each turn is a slow round trip and the context fills with raw data.

counties = get_counties("FL")                          # 67 at once
weather  = parallel_search(counties, "NOAA flood")     # all 67 in parallel
risk     = parallel_search(counties, "FEMA NRI flood")
joined   = join(weather, risk, key="FIPS")             # merge on county code
answer   = top(joined, by="flood_score", n=3)          # rank, take 3

That shape will look familiar — it is the same pipeline behind a lot of GIS and field-data work: CSV → geocode → enrich → join (FIPS) → rank → map. Search as Code says retrieval itself should be a step in that pipeline, not a chatbot asking a librarian one question at a time.

Result: the model writes the five lines, runs them once, and returns the three counties — no twenty-turn back-and-forth.

This is not really about search. It is about who orchestrates the work.

The speed in the demo is the eye-catching part. It is not the point. The point is what produced that speed: the AI wrote and ran the whole workflow itself. That is a shift in the architecture of operational software, and it reaches far past search.

Read that bottom row carefully. The AI is becoming the orchestration layer — the part that decides which sources to hit, in what order, how to combine them, and what to return. Less chatbot, more workflow architect sitting across your data, services, and decision-support systems.

For disaster response, GIS, and data operations that is immediate, because the work already looks like a pipeline: source → enrich → join → analyze → prioritize → report. What changes is that the AI can generate and run that pipeline dynamically.

The takeaway for anyone building operational platforms: the future is less "chatbot you ask questions" and more "AI as a workflow architect" — generating and orchestrating pipelines across data, services, and decision-support. The 2.5× is interesting; the shift is what matters.

This tab summarizes a Perplexity research article.

The explanation here is a plain-language walkthrough of Perplexity's piece on rethinking search as code generation, with the worked example reframed for GIS and field operations.

Manage AI risk seriously — and in proportion.

Kahneman's availability heuristic: we judge risk by how easily examples come to mind. AI is new, powerful, and constantly discussed, so it feels like the dominant data threat. But credential theft, phishing, mis-shared folders, lost devices, and uncontrolled exports still cause most real-world exposure.

Organizations lose data through eight familiar paths: exposed systems, stolen credentials, phishing, cloud-sharing mistakes, lost devices, misplaced documents, uncontrolled exports, and AI tools. AI belongs on that list as one category, not the whole list. A single compromised password or a mis-shared SharePoint folder can expose more than many AI scenarios.

The framework: fold AI governance into the existing data-exposure program (inventory, classify, set rules, monitor, train, measure) instead of isolating it as a special category that pulls attention from more frequent risks. Neither dismissal nor overcorrection: proportionality.

This tab summarizes a white paper.

A plain-language version of the draft white paper, with the argument kept intact.

GeoPandas and Matplotlib make static map products.

This is the Python path for maps that need to become PDFs, report pages, executive graphics, atlas pages, and reusable static outputs.

ArcGIS and web maps are best when the user needs to pan, click, filter, and inspect live layers. GeoPandas and Matplotlib are best when the output needs to be repeatable, printable, versionable, and polished as a finished artifact.

GeoPandas treats geography like a spreadsheet with shapes.

A normal pandas table has rows and columns. A GeoPandas table adds a geometry column, so each row can represent a county, chapter, facility, route, point, polygon, or line.

That unlocks the work that shows up again and again in Red Cross projects: joining counties to chapters, dissolving county polygons into chapter boundaries, clipping to a service area, and exporting a clean layer or map-ready table.

import geopandas as gpd

counties = gpd.read_file("counties.geojson")
metrics = counties.merge(county_metrics, on="FIPS", how="left")
chapters = metrics.dissolve(by="chapter_name", aggfunc="sum")
chapters.to_file("chapter-boundaries.geojson", driver="GeoJSON")

Plain version: GeoPandas is where the map's truth gets assembled before anything is drawn.

Matplotlib is the print shop for Python maps.

Matplotlib is not only for charts. With GeoPandas, it becomes a controlled map-rendering system: figure size, line weights, color ramps, labels, legends, titles, and source notes can all be scripted.

These examples are the kind of static outputs that are hard to keep consistent by hand but straightforward to regenerate when the code owns the layout.

FY27 Division and Region Map

A national division-and-region product with boundary hierarchy, labels, insets, and Red Cross styling. This is the flagship example from the Desktop FY27 Division outputs.

GeoPandasMatplotlibExecutive map

Florida Bridge Assistance by Chapter

Chapter boundaries are dissolved from counties, shaded by value, labeled directly, and exported as a report-ready map.

Chapter dissolveChoroplethLabels

North Central Florida Donor Map

A chapter-scale output from the chapter atlas pipeline: county-level donor values joined to geometry and rendered as a compact page graphic.

chapters.jbf.com outputCounty joinAtlas map

North Carolina BioMed Growth

Page one rendered from the BioMed growth PDF only as a PNG. Counties are shaded by change, with ranked fastest-growing and steepest-decline lists on the side.

BioMedPage-one PNGDiverging ramp

Florida Chapter Comparison Output

A generated chapter-intelligence report preview from the same ecosystem: static, repeatable, and ready to publish alongside maps and atlas pages.

chapters.jbf.com outputReport pageStatic publish

The examples come from existing local work.

The visual examples were pulled from Desktop FY27 Division outputs, the Chapter ED / chapters.jbf.com output family, and the North Carolina BioMed growth map supplied for this update.

Type the map you want. Let code make the map safely.

The embedded app below is the cleaner standalone shell for the Map Composer idea. It shows how a natural-language request should become validated Red Cross geography settings before any map is rendered.

Current truth: this is still a prototype. It parses known examples, locks the request to FIPS, ECODE, RCODE, and DCODE, and shows rendered sample outputs. It does not yet generate a new custom choropleth from an arbitrary text request.

Recent white papers and discussion briefs.

A broader library of recent papers, drafts, discussion briefs, strategy notes, and assessment explainers found under Desktop, the WhitePapers folder, RED CROSS, and Personal.

These are packaged directly with the Coding 101 site so they are easy to open, share, and reference from one place.

No papers match that search.

AI, search, and knowledge systems.

Plain-language papers and briefs about AI risk, sanctioned AI capability paths, search as code, and county-intelligence reasoning systems.

AI systems PDF July 2026

How Modern AI Systems Actually Work

A four-page field guide to LLMs, RAG, agents, MCP, memory, tools, deterministic code, guardrails, and the human responsibility around the whole system.

Open PDF

AI safety PDF June 2026

AI Risk and the Availability Bias Problem

Manage AI risk seriously, but keep it in proportion to the data-exposure paths that cause most real-world incidents.

Open PDF Read the plain version

Humanitarian AI PDF May 2026

The Humanitarian AI Blueprint

A visual brief on how AI can support Red Cross-style humanitarian work when it is grounded in operational context, governance, and human decision-making.

Open PDF

AI capability PDF June 2026

Beyond Copilot Chat

Two Microsoft-sanctioned paths for building with AI: Azure OpenAI and Copilot Studio, framed for peer discussion.

Open PDF

Builder tools PDF

Modern Builders Toolkit Briefing

A compact briefing on the practical tool stack for building, shipping, and learning in the AI-assisted software era.

Open PDF

Agent lessons PDF

Study Guide: What Salesforce Learned From 20,000 Agents

A study guide distilling lessons from large-scale agent testing into practical patterns for safer, more useful agent workflows.

Open PDF

Briefing skill PDF

Brief Skill Sample

A one-page sample showing how a reusable briefing workflow can turn source material into a tight executive-ready artifact.

Open PDF

AI adoption DOCX April 2026

Artificial Intelligence at the American Red Cross

A plain-language discussion of how AI can help save more lives faster when adoption is practical, governed, and mission-centered.

Open DOCX

AI governance DOCX Feb 2026

ArcGIS AI Tools Defense for AI Counsel

A business case for enabling Esri ArcGIS AI tools, focused on governance, boundaries, and practical GIS workflow value.

Open DOCX

AI economy PDF Feb 2026

AI, Disruption, and the Pattern of Prosperity

A personal essay on AI-driven disruption, prosperity cycles, and how to think about change without panic.

Open PDF

Search as Code PDF June 2026

Search as Code: Why This May Be a Bigger Shift

A short analysis of why search-as-code changes retrieval from a chat interaction into an executable reasoning workflow.

Open PDF Open SaC tab

Smart-Query PDF April 2026

Smart-Query Platform: Strategic Plan

A county-intelligence reasoning plan for a four-tool router spanning SQL, vector retrieval, tool use, and operational answers.

Open PDF

Smart-Query PDF April 2026

Smart-Query Platform: Today's Work

A working-session companion describing how app surfaces connect back to the same county-intelligence reasoning spine.

Open PDF

The iceberg image belongs with the AI risk paper.

The visual version makes the same argument as the paper: the visible AI risk is real, but the larger exposure surface includes credentials, phishing, cloud sharing, devices, documents, exports, and exposed systems.

Packaged with the site for direct sharing.

The PDFs, DOCX files, and AI-risk iceberg image are stored as static assets in this site, so the public links continue to work through the normal Vercel deployment.

Research papers, turned into working tools.

A monthly digest listed 31 geospatial papers. Most are academic. A few map straight onto disaster work — damage assessment, deployment routing, vulnerability mapping. Instead of just reading them, three of the methods were rebuilt as live browser demos.

This is the everyday agent move: take a paper's method, ignore its specific dataset, and stand up a small interactive version you can actually touch. The demos below run real algorithms on illustrative synthetic data.

Three methods, running in the page.

The embedded app has its own left-side navigation. Scroll inside the frame to reach Street Networks (betweenness for deployment routing), Change Detection (before/after damage swipe), and Vulnerability Index (weighted community ranking). Every control is live.

Three papers, three decisions.

Each demo answers an operations need, not an academic one.

Frame it this way: #6 and #8 reproduce against real public data today; #31's source was unverified in the digest. The demos use synthetic data to show the method, not findings.

Where this came from.

A standalone static page (one index.html, no build step) computes real Brandes betweenness, a procedural change-detection grid, and a weighted choropleth in vanilla JavaScript. Coding 101 embeds the live Vercel deployment instead of copying the code in, the same way the State Demo tab works.

A live map, built the same way.

One more example of the paper-to-tool move: a U.S. tornado map. Same recipe — a static page, real data, live controls, deployed to its own subdomain.

Fifteen ways a spatial interface can stop looking like a dashboard.

Most GIS dashboards are the same shape: a map, a fixed sidebar, a grid of static KPI cards. The Spatial Interface Lab is a working test bed for fifteen alternatives — interfaces that react to geography, the calendar, an active event, or what you clicked last — each built as a small live demo against real Red Cross data.

This is the same everyday-agent move as the GIS papers above: take an idea from exploration notes, stand up the smallest working version, and see if it actually changes how someone would use the tool.

All fifteen concepts, in one embedded app.

The embedded app has its own left-side navigation, starting on Overview. Scroll inside the frame and click any concept — the map becoming a menu, KPIs you can click to filter, a sidebar that reorders itself by what you use. Every control is live against real geography.

Fifteen patterns, one at a time.

Each concept replaces one static dashboard convention with something that responds to context.

Frame it this way: none of these are a redesign of one app — they're fifteen answers to the same question: what replaces a static menu when the interface already knows the geography, the date, and what you just clicked?

Where this came from.

A standalone Vite + React app (spatial-interface-lab) implementing fifteen interface concepts from a July 2026 exploration session, each concept its own component with a live demo, real Red Cross geography, and Calcite icons. Coding 101 embeds the live Vercel deployment instead of copying the code in, the same way the GIS Papers and State Demo tabs work.