Documentation Index
Fetch the complete documentation index at: https://docs.axiomancer.io/llms.txt
Use this file to discover all available pages before exploring further.
Restored Seattle council decisions and zoning variance ingestion
Two upstream issues that were silently dropping civic data have been corrected.Seattle council decisions were being filtered out of the Civic Intelligence dataset because Seattle’s Legistar template puts the bill number (for example,CB 121195) in the field most other cities use for the bill title. The development-keyword filter saw the file number, found no relevant terms, and discarded every Seattle matter. The Legistar HTML collector now prefers the canonical title and sponsoring-body fields and falls back to the legacy fields, so it works correctly across the San Francisco, New York City, Seattle, and Chicago templates simultaneously.Zoning variance records were also being lost. Every upsert raised a schema error because the writer was sending columns that don’t exist on the zoning_variances table — introduction date, agenda date, file number, vote tallies, and action history — and the per-row error handling swallowed the failures, so the collector logged successful fetches with zero stored records. The writer now maps the relevant dates to the filed_date and decision_date columns and routes the remaining fields through the source_record JSON column, so no source data is lost.If you query Seattle council decisions or any city’s zoning variances through the Locus API, the MCP server, or the Civic Intelligence schema, you should see records flowing again starting with the next collection run. No action is required on your part.Vessel density now renders as a shaded H3 hex map
The/dashboard/density page on Overwatch now renders the daily vessel density layer as a viridis-shaded H3 hex map instead of a top-cells table. Each cell’s polygon is colored by position count on a logarithmic scale, so dense traffic corridors and anchorage clusters read at a glance and tail-end activity stays visible alongside the hottest cells. Hover any cell to see its H3 index and exact positions_count and unique_vessels. The map is capped at 5,000 cells per render, fetches from the existing GET /api/v1/density endpoint, and respects the same vessel-type chip and day selector as before. The per-vessel-type rollup and freshness ledger indicator are unchanged. No action is required on your part.Locus admin routes now uniformly enforce the ADMIN_EMAILS allowlist
Every admin entrypoint on Locus — including the scoring-audit data fetcher at /api/admin/scoring-audit — is now gated by the same email allowlist used by the rest of /admin/*. The audit dashboard’s data route was previously protected only by “must be signed in,” meaning any authenticated free-tier user could read its payload; it now goes through the same requireAdminApi() check as every other admin API route, so requests from accounts not listed in ADMIN_EMAILS receive 403 Forbidden.Self-hosted and preview deployments must set the ADMIN_EMAILS environment variable to a comma-separated list of admin email addresses (for example, ADMIN_EMAILS=alice@example.com,bob@example.com) — when the variable is unset, all admin pages and admin API routes fail closed for everyone, and the server logs a warning explaining how to populate it. Hosted Locus is unaffected. The variable is now also documented in the example env file shipped with the repo so fresh setups don’t leave it blank by accident. No action is required if you already have ADMIN_EMAILS populated.Per-metro H3 resolution for low-density markets
Locus cell scoring now supports per-metro H3 resolution overrides. The default scoring resolution stays at H3 r8 (~0.74 km², ~490 m radius), which is right for dense urban grids — but in low-density, large-parcel metros an r8 cell often contains only a single CRE asset, leaving signal aggregation dominated by small-n noise. Ten metros are now scored at H3 r7 (~5.16 km², ~1280 m radius) instead so each cell carries enough samples to be statistically meaningful: Phoenix, Houston, Las Vegas, Dallas, San Antonio, Nashville, Jacksonville, Oklahoma City, El Paso, and Fort Worth. Every other metro continues to score at r8.Every row written tocell_scores is tagged with the resolution it was computed at via the existing resolution_variant column, so rankings, MAUP ensembles, and the explorer can distinguish r7 cells from r8 cells. If you query cell_scores directly across metros, filter or group on resolution_variant rather than assuming a single resolution. The override is additive — historical scores are unaffected and no action is required on your part. See Per-metro resolution overrides for the full list and rationale.general scoring profile rebalanced against CRE price-correlation literature
The default general scoring profile on /api/score has been rebalanced to align signal weights with the empirical commercial real estate price-correlation research. Three signals carry the strongest published correlation and clearest lead times against CRE prices and have been bumped accordingly: developmentPipeline (building permits, R² ≈ 0.55 vs CRE prices, 6–12 month lead) moves from 0.12 to 0.20, economicStrength (employment density change via LEHD, 3–9 month lead) moves from 0.15 to 0.20, and accessibility (transit ridership, 12–24 month lead) moves from 0.10 to 0.12. The +0.15 weight increase is offset by trimming less-validated groups so the weights still sum to 1.0: businessVitality 0.20 → 0.15, populationMomentum 0.15 → 0.10, demographics 0.12 → 0.10, amenityDemand 0.08 → 0.05. safetyEnvironment keeps its 0.08 — crime remains the peer-reviewed safety predictor and OSHA/EPA aren’t currently scoring inputs.The use-case profiles (qsr, office, industrial, retail, data_center, self_storage) are deliberately unchanged — they reflect industry-specific priorities rather than generic price prediction. If you call /api/score without a profile parameter (or with profile=general), expect composite scores to shift by a few points in either direction depending on the cell — cells strong on permits or employment density will trend up, cells primarily strong on demographics or amenities will trend down. Pin to the previous behavior with profile_version if you need replicable historical scores. See scoring profiles for the full weight table.Free location reports now require a captcha and email confirmation
The free location report form on Locus now runs requests through a Cloudflare Turnstile captcha and a double opt-in email confirmation before any report is sent. Previously, a single unauthenticated POST to/api/free-report would deliver an Axiom Locus Location Report to whichever recipient address the form named — with no captcha and no rate limit — which made the endpoint usable as a third-party email-bombing vector against non-consenting recipients on Axiom’s sender reputation.The form now renders a Turnstile widget and submits the resulting token alongside the address and email; the server verifies the token before doing any paid work (geocoding, scoring, sending). After the captcha clears, the request is rate-limited to 5 submissions per day per IP and 3 per day per recipient email. The endpoint then geocodes the address, queues a row with a 32-byte single-use token and a 24-hour expiry, and emails the recipient a confirmation link. Only after the recipient clicks the link does Locus actually score the location and send the report — so a report can never reach an inbox that didn’t explicitly opt in.The form redirects to a new /report-confirmed page with explicit success and error states (expired link, invalid or already-used token, scoring failure, send failure) so users can tell at a glance whether to retry. Re-clicking a confirmation link after it has been consumed is idempotent — the success page renders without re-scoring or re-sending. No action is required if you only consume Locus through the authenticated API; the consumer-facing free-report flow is the only surface affected.Safety tier mix on the Intelligence Rail
The Locus explorer Intelligence Rail now shows a Safety Tier Mix stacked-bar that breaks down how the active metro’s scored cells distribute across five safety tiers — Prime (≥80), Strong (60–79), Solid (40–59), Watch (20–39), and Elevated (under 20). Each segment is sized by the share of cells in that tier, so a glance answers “is this metro mostly safe, or mostly elevated?” without leaving the rail. A small legend below the bar shows the exact percentage in each tier and the total cell count powering the chart. The same component is built to render distributions for any of the eight signal groups in future updates — development pipeline mix, business vitality mix, and so on. No action is required on your part.Peer metro comparison band on the Intelligence Rail
The Locus explorer Intelligence Rail now includes a Peer Metros band that compares the active metro’s composite score against its three closest-by-composite peers as horizontal bars plotted against the absolute 0–100 scale. Because every row uses the same scale (instead of being normalized between rows), bar widths are directly comparable — useful for answering “is this metro actually strong, or does it just look strong?” Each peer row links straight to that metro’s pulse page, so jumping into deeper context for a comparable market is one click away. No action is required on your part.Nearby POIs collapsed into an accordion in the explorer sidebar
The Nearby POIs list in the Locus explorer sidebar is now collapsed into an accordion by default. POI is supporting due-diligence detail rather than a primary signal, so collapsing it keeps the at-a-glance Nearby summary badges and Crime Safety indicator in view without the long POI list pushing them off-screen. Expand the accordion to see the full list of nearby points of interest. No action is required on your part.Score sparkline and signal waterfall on the selected-cell panel
The selected-cell card at the top of the Locus explorer Intelligence Rail now shows two glanceable visualizations alongside the composite number. A 90-day score sparkline traces the cell’s composite trajectory with a trend-colored stroke — emerald rising, red declining, dim flat — and renders dashed at reduced opacity (with the label 90-day trajectory (estimated)) when the underlying series is a synthetic flat-trend stand-in for a cell with no real history, so estimated lines are distinguishable from real measurements. A signal-contribution waterfall plots the cell’s eight signal groups as horizontal bars sorted by score, with tier-colored fills and low-confidence groups dimmed and labeled in a tooltip. The two together replace the previous “what does the composite mean?” narrative with a comparison readers can interpret at a glance, while the full sub-signal breakdown stays available in the left sidebar’s score panel for users who want to drill in. No action is required on your part.Intelligence rail alongside the Locus explorer map
The Locus explorer now leads with intelligence, not geometry. The map narrows to about a quarter of the viewport width on large screens, and a new Intelligence Rail fills the rest with live alerts, top movers, monitored locations, and a metro-pulse snapshot — sourced from the same data that powers the signed-in dashboard. The cell-level score breakdown still lives in the left sidebar when you click a hex.A new mode toggle in the top-right of the map flips between the integrated view and the previous full-bleed map. Append?mode=fullscreen to the URL to land directly in the original sidebar-plus-large-map layout. Below the large breakpoint, the rail is hidden and the map fills the page so mobile and tablet keep a map-first layout.National activity mini-map on the Locus dashboard
The signed-in Locus dashboard now opens with a national activity mini-map between the page header and the stat cards, rendering the same 90-day heatmap as the explorer so the dashboard preview and the deep-dive read as one continuous surface. Click anywhere on the map to land in the explorer at that location with the score panel ready, instead of a generic map view, and use the Open Explorer button in the top-right for the full-map handoff. Heatmap palette and weight stops match the explorer exactly, so colors read identically across both surfaces. No action is required on your part.Tiny tracts excluded from Fastest-Growing by Population ranking
The public Fastest-Growing Neighborhoods (Population) ranking now filters out census tracts with fewer than 1,000 residents in the prior ACS vintage. Small-denominator tracts could otherwise dominate the list with mathematically true but practically meaningless percentages — for example, an industrial-to-residential conversion that grew from 62 to 2,382 residents would surface as +3,741% growth and outrank every actual neighborhood. The threshold keeps the ranking reflective of where real population is moving rather than where reclassifications happened. Column labels and the list description have been clarified to match. No action is required on your part.Nearby POIs collapsed by default on the explorer sidebar
The Nearby POIs list in the Locus explorer left sidebar now opens as a collapsible accordion that starts closed when you select a cell, so the long point-of-interest list no longer pushes the at-a-glance signal counts off-screen. POI is a supporting due-diligence detail rather than a primary nav element — most users only need to scan it after the higher-level signals already decide whether a cell is worth a closer look. The Nearby intelligence summary badges and the Crime safety indicator stay pinned above the accordion and continue to render without a click, so the headline counts (eateries, services, recreation, retail, and the safety read) remain visible the moment a cell is selected. Click the row labelled Nearby POIs — which now also shows the count of POIs available, e.g. 15 shown — to expand the full styled-tile list with photos, distance, ratings, and the per-POI detail expander. Re-clicking collapses it again. No action is required on your part.SAR fusion no longer biases risk_score downward when no radar observation was attempted
The Dempster–Shafer Yager fusion inside verify-dark-fleet-sar previously placed 0.7 belief mass on Lawful whenever the SAR pixel detector returned null — i.e. whenever a SAR check wasn’t even attempted (low or medium SAR-coverage potential, missing Copernicus credentials, or a detectShips exception). Because the fusion always combined that mass with the AIS prior, every event without a SAR observation came out with a fused risk_score lower than its pre-fusion AIS score, systematically pulling unscored events away from high and critical.Fusion now distinguishes three cases. If pixelDetection is null (no observation attempted), SAR contributes pure ignorance (mass(L,D) = 1.0), so the fused score equals the AIS score. If a strong CFAR detection lands (maxConfidence > 0.6), behavior is unchanged — SAR corroborates the dark-event signal proportional to its confidence. If a detection ran but returned weak pixels, the lawful lean is reduced from 0.7 to 0.3 to account for cloud cover, scene-edge clipping, and side-lobe artifacts that are common in real Sentinel-1 scenes. The bug had been latent since the pipeline shipped — with risk_tier recalibration now feeding ~1,700 high+critical events into the fusion path on every run, leaving it would have started biasing scores at the next 08:00 UTC sweep.If you consume risk_score from /api/v1/risk/events, /api/v1/risk/vessels, or the dark_event webhook, expect scores on high and critical events with no SAR observation to settle at their pre-fusion AIS values rather than a depressed fused value. Events with strong SAR detections continue to surface at risk_score = 100. See SAR detections storage for the full pipeline and Risk tiers for tier semantics.Dark event risk_tier thresholds re-calibrated against the production score distribution
The risk_tier cutoffs applied to every dark event have been re-calibrated so the high and critical buckets actually fire. The original thresholds (low ≤ 25, medium ≤ 50, high ≤ 75, critical > 75) assumed the 13 risk factors would compound — sanctions match plus STS involvement plus identity manipulation plus a high-risk flag — but most real dark events are isolated AIS gaps where those columns are zero, so the score formula’s effective ceiling lands well under the old high boundary. Across 26,326 production events the observed distribution was min 5, p50 12, p90 23, p95 27, p99 30, max 42, which meant zero events ever scored high and the downstream verify-dark-fleet-sar pipeline starved on every run despite the SAR infrastructure being live.The new thresholds are calibrated against actual percentiles: low ≤ 15 (~p65), medium ≤ 25 (~p65–p93), high ≤ 35 (~p93–p99.5), critical > 35 (top ~0.5%). A backfill of existing rows shifted the live distribution from 24,624 / 1,702 / 0 / 0 to 18,888 / 5,736 / 1,683 / 19, so the SAR pipeline now has roughly 1,700 high+critical events to verify on its next run.If you filter /api/v1/risk/events, /api/v1/risk/vessels, or the dark_event webhook by risk_tier, expect high and critical to start returning results where they previously returned nothing — and medium to shed roughly the top half of its previous population into high. The numeric risk_score field is unchanged on every event; only the tier-bucket boundaries moved. See Risk tiers for the full table and rationale.Global vessel density by type, bucketed into daily H3 cells
Overwatch now ships a global vessel density surface built on a daily H3 resolution-8 (~0.74 km² per cell) matview joined fromais_positions to vessel type. Per-IMO-per-hour bucketing means vessels broadcasting every 10 seconds don’t swamp vessels broadcasting hourly, so density reflects time-on-station rather than ping cadence — useful for spotting traffic corridors, anchorage clusters, and class-specific hot spots on a given day.Query it via the new GET /api/v1/density endpoint with type (defaulting to bulk_carrier, or all to aggregate across types) and day (defaulting to yesterday UTC) parameters. The matview holds a rolling 30-day window and is refreshed nightly at 02:00 UTC after the previous day’s bucket closes. A new /dashboard/density page in the Overwatch app shows per-type rollups and the top H3 cells alongside a freshness indicator from the underlying derived_views_freshness ledger. No action is required on your part.Faster vessel popup loads on the live map
Clicking a vessel on the Overwatch live map now opens the popup card noticeably faster, especially when the live weather provider is slow to respond. The vessel context endpoint that powers the popup previously waited up to ~4.5 s for the upstream live-weather fetch to resolve before falling back to the cachedport_weather snapshot — so a degraded weather upstream pushed total popup latency past 4.5 s even though a usable cached value was available the whole time. The endpoint now runs the live fetch and the cached fallback concurrently and returns whichever resolves first with usable data, so popup latency is bounded by the faster of the two paths instead of the sum. No action is required on your part — the speedup applies automatically the next time you click a vessel.Improved vessel icons on the live map
Vessel markers on the Overwatch live map now use elongated triangles that match the industry-standard silhouette you see on VesselFinder and MarineTraffic. The narrower, bow-forward shape makes it easier to read heading direction at a glance. Vessels are also more visible at world and regional zoom levels, so you can spot traffic patterns without needing to zoom in.Live map now features the Port of Long Beach
The default hero map location has moved from the Bosphorus Strait to the Port of Long Beach, giving you an immediate view of one of the busiest container ports in the Western Hemisphere when you first land on Overwatch.Tiny tracts no longer dominate the Fastest-Growing by Population ranking
The public Fastest-Growing Neighborhoods (Population) ranking now filters out census tracts with fewer than 1,000 prior residents, so small-denominator anomalies — for example, an industrial-to-residential conversion that grew from 62 to 2,382 people and showed as +3,741% — no longer dominate the leaderboard. The list now reflects what a reader looking for “fastest-growing neighborhoods” actually expects: meaningful population growth in inhabited areas. Column labels and the list description were sharpened to match — Population Change % (5-year ACS), Population (latest vintage), Population (5 years prior) — so it’s clearer that the percentage is a roughly 5-year delta rather than a single year. The composite Fastest-Growing Neighborhoods (Axiom Composite) list is unaffected. No action is required on your part.Faster Layer dashboard load times
The Layer dashboard now loads roughly 450–1200 ms faster on first paint. The page previously fetched its hardware costs, employee costs, and security discovery panels in three sequential round-trips before rendering; those calls now run in parallel, so total time-to-first-byte is bounded by the slowest single fetch instead of the sum of all three. The assets listing page also fetches a narrower column set tailored to the table view, avoiding pulling raw payload and wide metadata blobs over the wire on large tenants. No action is required on your part — the speedup applies automatically the next time you load the dashboard.Dedicated AI Usage page powered by RouteShift
Layer now has a dedicated AI Usage entry in the dashboard sidebar, between Hardware and Renewals, for tracking LLM spend per employee across OpenAI, Anthropic, Google, and other providers. The page introduces RouteShift — the LLM proxy gateway behind Layer’s AI cost tracking — with a one-click Open RouteShift handoff for managing per-employee keys, smart routing, savings, and live analytics (cache hit rate, p95 latency, error rate, and savings reporting on daily, weekly, or 24-hour windows). Per-employee spend roll-up directly inside Layer is on the roadmap; until then, the existing per-person, department, and provider ROI views remain available via the AI usage tracking feature. No action is required on your part.Demo mode for fully-populated synthetic workspaces
Layer organizations can now be flagged as demo tenants, turning the workspace into a fully-populated synthetic environment for prospects, training, and internal walkthroughs. A demo organization renders a pink Demo data banner under the cross-product bar on every dashboard page and exposes a new Demo mode card in Settings with a one-click Reset demo data action. Resetting wipes nine tenant-scoped tables in foreign-key order and re-seeds them with 60+ SaaS apps across productivity, dev, security, compliance, finance, HR, marketing, sales, and AI categories, 12 months of monthly spend per app, 18+ contracts spread across the next 12 months of renewals, 12 months of AI usage across OpenAI, Anthropic, and GitHub Copilot, plus a realistic mix of active andneeds_reauth integration connections. Reset is admin-gated and the server hard-refuses unless the organization is explicitly flagged as demo, so real customer tenants can never be wiped through this endpoint. See Demo mode for the full walkthrough. No action is required on your part.Explicit workspace setup step on first sign-in
Layer no longer auto-creates a workspace named after your email domain when a new user reaches the dashboard, an integration connect callback, or the free shadow IT scan without a workspace already set up. Previously, signing in could silently land you as the owner of a brand-new “Gmail” or “Acme” workspace based on your email — a path that could cross-pollute identity in invitee and SSO flows. New users without a workspace now go through a short Create your workspace step that asks for an explicit workspace name before continuing. Existing workspaces, sign-ups that already include a workspace name, and users invited into an existing workspace are unaffected. See Getting started. No action is required on your part.Per-vessel ETA and route-waypoint forecasts
Every vessel currently in transit — with a recent AIS position, a declared destination, and clear of any port zone — now has an hourly route forecast that projects an eight-point great-circle arc from the vessel’s current position to its destination port, with an ETA distribution (p10 / p50 / p90) at each waypoint. Forecasts refresh hourly and fall back to a per-class typical cruise speed when a vessel’s reported speed is too low to be predictive (for example, a stopped vessel that hasn’t yet departed). Use it to anticipate arrival windows, plan berth assignments, and surface vessels likely to slip their declared ETA. See the forecasts API for query patterns.Expected arrivals and voyage-times dashboard panels
The data behind per-vessel route forecasts and voyage time-allocation now has dedicated dashboard surfaces in the Overwatch app. The forecasts page at/dashboard/forecasts/[port] now includes an Expected Arrivals panel that lists vessels forecast to arrive at the port inside a rolling 7-day window, with the ETA p50 and the p10/p90 spread shown as a “window” column so you can see at a glance which arrivals are tightly bounded versus loosely projected. The new /dashboard/[port]/voyage-times page renders per-visit stacked bars (approach / anchor wait / berth / idle other), median summary cards, and a 50-row drill-down table — useful for comparing turnaround efficiency across recent visits at a single port. Both panels share the dashboard’s terminal-style chrome and gracefully empty-state when the underlying data hasn’t been populated yet. See the forecasts API and vessel visits API for the underlying queries.Voyage time-allocation reports per port visit
Every closed vessel visit now carries a sibling time-allocation breakdown that splits arrival → departure into hours spent on approach, anchor wait, berth, and idle other — answering the “where did the time actually go?” question that aggregate berth hours alone couldn’t. Allocations are computed on every departure close and a one-time backfill is populating historical visits. Useful for benchmarking turnaround efficiency, attributing congestion to anchor versus berth bottlenecks, and quantifying how much of a long visit was real loading work versus waiting offshore.Stripe checkouts now reliably activate paid Overwatch plans
Customers completing a paid Overwatch checkout could previously remain on the free plan after a successful Stripe payment. The webhook handler claims an idempotency row before applying side effects (so a Stripe retry of the sameevent.id doesn’t re-run the upgrade), but the underlying processed_stripe_events table was missing in the production database. The insert silently failed, the handler treated every webhook as a duplicate, and the matching subscriptions row was never written — so checkout completed on Stripe’s side but the account stayed on the free tier.The table is now in place, every checkout.session.completed, customer.subscription.updated, and customer.subscription.deleted event applies its side effects exactly once, and Stripe retries are correctly deduplicated rather than skipped. If you completed a paid checkout recently and your account stayed on the free plan, contact support — or re-trigger entitlement sync from your billing portal — and the correct plan and current_period_end will populate. No action is required if your subscription is already showing the correct plan.