⓪ Not a CRM — an index that learns from you loading growth numbers… ▸ click to expand
If you've worked on a legacy staffing CRM, your mental model is field inventory — every concept must be a visible column, dropdown, or checkbox, or it doesn't exist. This system works the opposite way: concepts don't need to be pre-declared because the hybrid index + playbook memory learns them when you work a contract. The rows below translate the familiar legacy surface into what actually happens here, with real numbers for every claim.
Live from the City of Chicago Open Data permit feed (Building Permits ≥ $250K), cross-referenced against our 500K-worker bench. The console on the left is the punch clock — current time, today's active shift, and four dials watching open permits, workers needed, bench depth, and projected coverage. The panel on the right reads the same feed financially: combined bill demand if every permit fills, deadline pressure across overdue / urgent / soon / scheduled, the four roles being asked for most, and a shift-mix bar. Click any shift bar to re-slice the dials and the dollar counter to that shift's calendar slice; click again to clear. The same permit feed drives the staffing forecast, the staffer's console, and worker matches further down — this row is its heartbeat.
This is what a recruiter or coordinator sees when they open the console. Each card is one open permit ranked against our 500K worker bench. The fill-probability bar shows cumulative chance of filling by day; the economics panel projects gross revenue, margin, and payout window; the over-bill pool flags workers whose pay exceeds the contract's bill rate — they go into a margin-watch bucket instead of being rejected outright.
Type a plain-English description — role, location, trait, certification. The query hits the hybrid SQL + vector index over all 500K worker profiles and ranks by semantic match, reliability, and availability. Try one of the sample searches below or write your own.
Each tile is a capability the system has acquired and the live metric proving it's running. Operational learning (fills, playbooks, hot-swaps) compounds inside each capability; what changes here is the set of things the substrate knows how to do. The architecture is metro-agnostic — every capability replicates by config, not code.
These tiles measure the architecture itself, not the staffing workload. Instant-search latency, index shape, playbook-memory depth, pathway-matrix compounding — four probes that answer "is the substrate healthy right now?"