[lab] everything runs in your browser · synthetic data

Lab interactive

Each demo isolates one mechanism from a real project — a sync strategy, a race condition, a security trap — so you can break it yourself. Numbers are synthetic; the mechanics are the real ones.

01 /Agent Graph Run

One ticker through the 12-role graph: parallel analysts, two debates, a final rating — and the divergence check against the optimizer.

Self-Hosted Multi-Agent Research · view case study →

what you're seeing

Each node is an agent. The four analysts on the left run in parallel; Bull and Bear debate; the Research Manager and Trader turn that into a plan; three risk profiles argue; the Portfolio Manager decides. The card on the right compares the rating with the weight the optimizer gave the same asset.

try this

  1. 1.Press Run analysis and watch which nodes light up together.
  2. 2.Run it a few times — when the rating comes out Sell while the weight is high, the divergence warning appears.
  3. 3.Raise the speed to see the shape of the graph instead of the text.

real vs simplified

The messages are scripted, not live LLM output, and the asset is fictional. The graph's shape is the open-source TradingAgents design; the parallel fan-out, the macro context given to the Portfolio Manager and the divergence check are my additions.
[lab] loading demo…
02 /Will It Fit? VRAM Simulator

Model size, quantization, context and KV cache against a GPU's memory — with layers spilling to RAM and the speed you'd get.

Local LLM Lab · view case study →

what you're seeing

The bar is GPU memory: weights (cyan), KV cache (lime), runtime overhead (grey) and the budget line (amber). Below, each square is a transformer layer — on the GPU or spilled to system RAM, which is what makes generation crawl.

try this

  1. 1.Start at 9B · Q4_K_M · 8 GB laptop with 32k context: it doesn't fit while the display uses the GPU.
  2. 2.Turn on “move display to iGPU” — the last layers come back to the GPU.
  3. 3.Switch to 27B · AWQ on 24 GB, then on 48 GB, and shrink the context to 16k.

real vs simplified

The scenarios match my setup (9B with 33 layers on an 8 GB laptop GPU; a 27B AWQ build that ran out of memory on 24 GB and runs on 48 GB). Memory and speed formulas are rough estimates, not a benchmark.
[lab] loading demo…
03 /Agent Harness Session

A coding agent adding a data source: context, read-only tools, automatic checks — and a human approval at the end.

Agent Harness & Context Engineering · view case study →

what you're seeing

A replay of an agent session on the left; on the right, the harness layer each line belongs to. Context is memory (vault, knowledge graph); capabilities are skills and read-only tools; guardrails are hooks and invariants; nothing merges without the human step.

try this

  1. 1.Watch an invariant fail in the middle and the agent fix it using a note from memory.
  2. 2.At the end, approve or reject — rejection sends the plan back.
  3. 3.Replay at higher speed to see the layers alternate.

real vs simplified

The session is fictional and condensed. The structure — read-only MCPs, a vault as memory, a knowledge graph, invariants and a human-only merge — is how I actually work.
[lab] loading demo…
04 /Efficient Frontier Playground

Thousands of random portfolios of 8 synthetic assets, regime caps per asset class, and the max-Sharpe portfolio.

Macro-Aware Portfolio Optimizer · view case study →

what you're seeing

Each dot is a random portfolio: risk on the x axis, expected return on the y axis, color by Sharpe ratio. The ringed dot is the best Sharpe; on the right, its weights. The regime buttons apply each regime's caps per asset class.

try this

  1. 1.Turn sparse sampling off and on — without it, the cloud never reaches the upper edge.
  2. 2.Switch from a dovish to a hawkish regime and watch crypto and equities shrink.
  3. 3.Lower the number of simulations to see how noisy the optimum gets.

real vs simplified

Sampling is the real method (uniform Dirichlet, sparse Dirichlet 0.3 and blends toward the optimum). Assets, returns and caps are synthetic, and the real system finds the optimum with SLSQP instead of picking the best sample.
[lab] loading demo…
05 /Macro Regime Classifier

Central-bank bias × growth, the rate-level override, an event study and the dampened macro alpha it produces.

Macro-Aware Portfolio Optimizer · view case study →

what you're seeing

The sliders set the central bank's bias, growth and the policy-rate level; the grid shows the resulting regime and its constraints. Below, a past event's reaction per asset class at T+1, T+5 and T+20, and how much of it becomes an adjustment to expected returns.

try this

  1. 1.Push the bias to dovish, then raise the rate above 10%: the override reads the cut as normalization (neutral).
  2. 2.Pick each event and compare the raw reaction with the final adjustment.
  3. 3.Notice the clip: a big reaction never moves expected returns by more than the cap.

real vs simplified

The rules are the real ones (10% floor for Brazil's policy rate, 30% dampening, clipping). Events, reactions and asset classes are fictional; the real system finds similar past events by vector search.
[lab] loading demo…
06 /Checksum Mirror Sync

Only months whose checksum changed are copied, one per self-chaining invocation, through a shadow table and an atomic publish.

Sync Engine: Legacy MySQL → Postgres Mirror · view case study →

what you're seeing

Left: the legacy database, one row per month with COUNT and SUM. Right: the Postgres mirror. In the middle, the edge function: it compares checksums, queues the months that differ and processes one per call. Below, the daily rebuild split in 4 chains, each tracking what it still owes.

try this

  1. 1.Click Mutate legacy, then Run sync: only the amber months travel.
  2. 2.Switch to “all at once” and run again — memory blows past the limit.
  3. 3.In the daily rebuild, turn on “chain dies silently”: the dead chain stays visible as pending work.

real vs simplified

Units, checksums, shadow table, atomic publish and pending-per-chain are how the real sync works. Tables, sizes and the memory limit are illustrative.
[lab] loading demo…
07 /Swap Races on a Legacy MySQL

Two real incident patterns: zeros from a LEFT JOIN during an external rewrite, and an index that dies at every swap.

Legacy MySQL Forensics · view case study →

what you're seeing

Tab A: a timeline with the window when an external ETL leaves a source table empty, the rebuild query, and the three tables of the RENAME swap. Tab B: 24 hourly runs of a 17-step refresh, where an external swap drops an index and a guard has to win a lock race.

try this

  1. 1.Tab A: move the rebuild into the amber window and run it — two columns turn to zero and the log still says OK. Then restore from _stage.
  2. 2.Tab B: watch which hours abort, then turn on the fixes one at a time.
  3. 3.Compare the abort rate between “guard ok” and “guard gave up” in the correlation table.

real vs simplified

Both mechanisms happened on the real database and were proven this way. Tables, times and rates are synthetic.
[lab] loading demo…
08 /Multi-Source Architecture Map

Twelve fictional sources tagged PIPELINE, RULER or CONFERENCE, two tracks into the dashboards, and a manual source going stale.

Multi-Source Data Architecture · view case study →

what you're seeing

Sources on the left, the two hubs in the middle (lake gold and Postgres), dashboards on the right. Each source has a kind, grain, cadence, owner and failure mode; the colored dot is its freshness.

try this

  1. 1.Click a source to trace its path to the dashboards.
  2. 2.Filter by RULER and CONFERENCE — they're never ingested like a pipeline.
  3. 3.Click “manual source goes stale” and see which dashboards inherit the warning.

real vs simplified

The classification and the two tracks are the real design. Source names are generic and the wiring is simplified.
[lab] loading demo…
09 /Medallion Lake Explorer

The same orders through landing, bronze, silver and gold — dedupe, typing, UTC, canonical statuses and a two-currency mart.

Canonical Marts on a Medallion Lake · view case study →

what you're seeing

Four layers of a lake. Click one to see what the same three orders look like there: raw JSON, typed Parquet, cleaned and deduplicated rows, and a gold mart row. The IaC tab shows which infrastructure modules touch each layer.

try this

  1. 1.Go from Landing to Silver and spot the duplicate order disappearing and the timestamp moving to UTC.
  2. 2.In Gold, switch USD/BRL: every money column exists in both currencies.
  3. 3.Read the partition-pruning note — it's the most common reason a mart query scans everything.

real vs simplified

Layer conventions and the gold rules are the real ones. Orders and module names are fictional; the lake itself is team work, my part was the marts.
[lab] loading demo…
10 /Proportional vs Exact Attribution

Why splitting spend by page views misleads, and the two fixes that made exact attribution add up.

Performance-Marketing Reporting Backend · view case study →

what you're seeing

A small table of days × landings × video players with cost, views and revenue. On the right, cost and revenue per creative under each method, and whether totals add up.

try this

  1. 1.Start in proportional mode: a day with spend but no views loses its cost.
  2. 2.Switch to exact, then turn on “union of all landing-dates” — the lost cost comes back.
  3. 3.Turn on “collapse per player” to stop a shared player's revenue from counting twice. Then add a new creative.

real vs simplified

The two failure modes and their fixes are the real ones from the client's attribution views. All rows are synthetic.
[lab] loading demo…
11 /Who Can Call This Function?

Grants to PUBLIC, anon and authenticated, SECURITY DEFINER, RLS and an internal guard — tested against four callers.

Postgres RPC Exposure Audit · view case study →

what you're seeing

A Postgres function that returns contacts, with toggles for its grants and protections. On the right, what four callers (anonymous with the public key, member, master, owner) get back. Below, the audit query that finds exposed functions.

try this

  1. 1.Click “REVOKE FROM anon” — anonymous still gets 200. That's the PUBLIC trap.
  2. 2.Now revoke from PUBLIC and anon: anonymous is out, but the member still reads master-only rows.
  3. 3.Turn on the internal role guard: each role sees only its tier.

real vs simplified

The grant inheritance, SECURITY DEFINER bypassing RLS and the audit logic are real Postgres behavior. The function and its data are fake and masked.
[lab] loading demo…
12 /Dashboard Hub Patterns

The hub's conventions in one panel: heat table to the cent, two themes over one data palette, cuts by role and a CSV that equals the card.

Analytics Dashboards Hub · view case study →

what you're seeing

A miniature dashboard: KPI cards, a trend chart, the offer funnel (front, order bump, upsell, downsell), a heat-colored table and the CSV it exports. The switches on top change theme, period and the role you're viewing as.

try this

  1. 1.Switch theme: surfaces change, data colors don't.
  2. 2.View as Member: order counts and AOV disappear — from the table and from the CSV.
  3. 3.Change the period and check that the CSV preview always matches the table.

real vs simplified

The conventions are the hub's real ones; roles are owner / master / member as in production. Numbers are synthetic and the layout is condensed into one panel.
[lab] loading demo…
13 /Contribution Margin Waterfall

Revenue down to contribution margin, projected net vs “refunds so far”, refund development curves and a factors table.

Executive Margin Cockpit · view case study →

what you're seeing

A waterfall from revenue to contribution margin, one bar per cost factor. Below, refund curves by cohort with the 180-day projection, a backtest of projected vs realized refunds, and the factors table that feeds every bar.

try this

  1. 1.Switch to “net with refunds so far” and set the sale age to 7 days — the margin looks much better than it will be.
  2. 2.Drag the age toward 180 days and watch the gap close.
  3. 3.Click a row of the factors table to highlight where it enters the waterfall.

real vs simplified

The rule (net is always projected), the curve's shape and the factors-table idea are real. The cost structure and every number are synthetic.
[lab] loading demo…
14 /Lead Latency Pipeline

A live stream of lead events to SMS, e-mail and call center: latency buckets, p50/p95 per channel, a stuck tray and the routing matrix.

Lead Processing Latency · view case study →

what you're seeing

Dots are lead events traveling from the integration database to each channel. Below: a latency histogram, percentiles per channel, the match rate, a tray of stuck pairs, a per-lead Gantt and the matrix of which event goes to which channel.

try this

  1. 1.Pause SMS: dots pile up as stuck and the match rate drops — then resume and they're delivered late.
  2. 2.Switch Events ⇄ Leads to see how much the unit changes the match rate.
  3. 3.Tap a dot to open that lead's Gantt; check the matrix — unrouted pairs never count as stuck.

real vs simplified

The definitions are the dashboard's (finalized per channel, routed pairs only, events vs leads, time per stage). Time is compressed and the traffic is synthetic.
[lab] loading demo…
15 /If It Can Be Recomputed, It Wasn't Hidden

Member vs master cuts of one dashboard, with a live leak detector and the CSV export trap.

Tiered Affiliates Dashboard · view case study →

what you're seeing

The KPI cards a member or a master sees. You choose what to hide from members; the leak detector checks whether a hidden number can be rebuilt from what's left — on screen or in the exported CSV.

try this

  1. 1.As Member, hide only AOV: the detector shows it leaks through revenue ÷ orders.
  2. 2.Hide order count too — now the cut is consistent.
  3. 3.Turn on CSV export: the file carries the hidden columns until “CSV follows the screen cut” is on.

real vs simplified

The rule and the leak paths are the real ones behind the affiliates dashboard. The program and its numbers are fictional.
[lab] loading demo…