Elie Hasbani

I build working systems across devices, data and applied AI.

Data engineer. I design these systems and decide what counts as proof; AI coding agents write most of the code under my direction.

  1. A tour of the platform's sections in its own interface style, with figures extracted from its registry, run ledger, knowledge graph and design store. Projects are shown as counts, not names.

    Partial

    BigBrain

    BigBrain is the system the other projects are built inside. It keeps a registry of 36 internal projects and 131 studied external repositories, with their ports, status and health. Work is started and watched in BigTerminal. What the work teaches is kept in a provenance-tracked knowledge graph, and design quality has its own research lab. Models, budgets and providers are governed in one place, so every run's route and cost can be checked afterwards.

    Skills shown

    How it runs

    1. Every estate project is registered with its ports, status and health
    2. Start, stop and open project servers from one page
    3. Start AI work against a project in BigTerminal
    4. Models, providers and budgets are governed in one place
    5. What the work teaches is kept in the knowledgebank
    6. Each run’s route and cost can be audited afterwards

    Layers

    1. Operations
    2. Interface
    3. Intelligence
    4. Data
    5. Backend

    Stack

    React · TypeScript · Vite · Node.js / Express · SQLite · Server-Sent Events · MCP · Claude Code · OpenRouter · Ollama

    • Compiles one registry of the estate from the projects themselves, with the provenance and confidence of every field.
    • Shares model routing, provider capacity and budget ceilings across every run, with a free-routes-only mode enforced before each call.
    • Exposes project context to external coding agents over MCP.
    View project
  2. Replay of one real working day from the run ledger, in BigBrain's own interface style: real order and overlaps, idle gaps shortened. Runs on projects not listed here are left out.

    Proven

    BigTerminal

    You give it a goal from the browser or the terminal, or queue several. Each run gets a supervisor model, workers in their own Git worktrees and a reviewer that is a different model from the writer. Routing chooses across Claude, OpenRouter and local Ollama, and an operator pin can overrule it. A rate-limited provider parks the run until its reset time instead of failing it. Every attempt records its model, tokens, time and cost, and nothing completes until the Definition of Done passes.

    Skills shown

    How it runs

    1. Give it a goal from the browser or the terminal
    2. Routing picks a provider and model; an operator pin can overrule it
    3. A supervisor model plans the work as structured directives
    4. Workers carry it out in isolated Git worktrees
    5. A different model reviews the change
    6. Definition-of-Done checks decide whether it counts
    7. The result lands with its model, tokens, time and cost recorded

    Layers

    1. Operations
    2. Interface
    3. Intelligence
    4. Data
    5. Backend

    Stack

    React · TypeScript · Node.js / Express · SQLite · Server-Sent Events · Git worktrees · Claude Code · OpenRouter · Ollama · MCP

    • Routes each task across cloud and local model providers, and records why a route was chosen or overruled.
    • Runs worker agents in separate Git worktrees, so parallel AI writers cannot overwrite each other or the operator's work.
    • Refuses completion until every Definition-of-Done item has passed with evidence. Green implementer tests alone are not accepted.
    View project
  3. Illustration of the real pipeline. The figures are measured on the system’s fully synthetic medium-tier campaign; sheets, coverholders and carriers are drawn.

    Partial

    Bordereaux Management System

    Coverholders send monthly spreadsheets of policies, premiums and claims. It keeps each original file untouched, maps its columns, checks every row against versioned rules and the binder's terms, and routes problems to an exception workflow where nobody approves their own fix. What it publishes is an event history with exact capacity splits, queryable by every party to the contract, and every published value traces back to the spreadsheet cell it came from.

    Skills shown

    How it runs

    1. A coverholder uploads a spreadsheet; the original bytes are kept unchanged
    2. Columns are mapped; an uncertain mapping waits for a data steward
    3. Every row is checked against versioned rules and the binder's terms
    4. Errors are corrected or waived by someone other than the requester
    5. An approver publishes; events, splits and audit commit together
    6. Any value traces back to its source cell, and past states can be replayed

    The full-scale simulator rerun on the final code was interrupted; the smaller runs pass on it.

    Layers

    1. Operations
    2. Interface
    3. Data
    4. Backend

    Stack

    Node.js · node:sqlite · React · TypeScript · Vite · Vitest · Playwright · axe-core

    • On a simulated market of 497,284 policies, every policy, claim, carrier total and point-in-time view matched the simulator's independent ledger exactly.
    • A separate reviewer attacked the code and confirmed 15 defects; each fix has a test that was shown to fail on the old code.
    • Access is checked on the server for every page, export and query; ad-hoc SQL runs read-only in an isolated process, limited to the caller's contracts.
    View project
  4. The real graph (node types and edges; the layout is seeded) and one real retrieve, use and write-back loop from the run ledger. Only that task's own nodes are labelled.

    Partial

    BigBrain Knowledgebank

    Every accepted piece of AI work writes back what it learned: a fact, gotcha, decision or lesson, tied to its project and its evidence. Before the next task, the relevant nodes are retrieved and injected into the supervisor and workers within a token budget, and each worker reports which ones it actually used. Writes are transactions with before-and-after SHA-256 hashes and a byte-exact rollback, so a bad memory can be removed for good.

    Skills shown

    How it runs

    1. Accepted work writes back a fact, gotcha, decision or lesson
    2. Each write is a transaction with before-and-after hashes
    3. The next task retrieves the relevant nodes within a token budget
    4. Supervisor and workers receive them with the brief
    5. Each worker reports which nodes it actually used
    6. Wrong or outdated knowledge is superseded or rolled back

    Layers

    1. Interface
    2. Intelligence
    3. Data

    Stack

    Node.js / Express · React · D3 · SHA-256 · MCP · node:test

    • Retrieval is benchmarked on held-out questions: the right node is in the top three 0.917 of the time, with zero polluted results.
    • Workers report which injected nodes they applied, ignored or found stale. The recorded application rate is 0.348.
    • New knowledge supersedes old knowledge instead of overwriting it, so the history of what was believed stays inspectable.
    View project
  5. Illustration of the real flow. The cube’s screen is a real framebuffer capture from a Sprite unit and the pack’s own character frames; the pack sizes are measured.

    Partial

    Sprite

    The phone puts the device on Wi-Fi through a protected temporary access point. From then on the device talks to a Node server, which plans content packs to fit its flash, sends them in chunks over authenticated APIs and reads back device health. Firmware changes count as proven only when they work on flashed hardware, with a rollback build kept. A successful compile is not enough.

    Skills shown

    How it runs

    1. The phone puts the device on Wi-Fi through a protected access point
    2. The device registers with its content server
    3. The server plans content packs that fit the device’s flash
    4. Packs are sent in authenticated chunks
    5. The device shows the content and reports its health back

    Layers

    1. Operations
    2. Interface
    3. Data
    4. Backend
    5. Connectivity
    6. Device

    Stack

    ESP32-S3 · C++ · PlatformIO · Python · Node.js / Express · SQLite · Expo / React Native · TypeScript · Wi-Fi SoftAP · LittleFS

    • Moved commissioning from Bluetooth to a protected Wi-Fi access point after measured Bluetooth/Wi-Fi coexistence failures.
    • Found a production security guard that never compiled because of build flags, and a heartbeat path that leaked a device token. Both were closed and re-verified on hardware.
    • Shrank a starter content pack from about 114% of the flash filesystem to about 62% by de-duplicating identical files in a generated profile, without deleting the originals.
    View project
  6. Recorded from the running app and its engine, three seconds on each page; page-change and query waits are shortened. The athletes and telemetry are simulated, not historical footage.

    Partial

    SportsVis

    A live sports laboratory where fictional competitors act autonomously. Watch from above, open the professional desk and make a strategic change without stopping the action. A read-only SQL studio exposes the same simulation state, and an engineering handbook explains the models and their limits. The demo runs locally on the owner’s machine.

    Skills shown

    How it runs

    1. Watch a shared autonomous sports session
    2. Open the professional desk and select a participant
    3. Apply a legal strategy change and observe its consequences
    4. Inspect the recorded samples in a read-only SQL workbench
    5. Read the engineering handbook and its disclosed limits

    Synthetic models are deliberately simplified; local operation is verified separately from public hosting.

    Layers

    1. Operations
    2. Interface
    3. Data
    4. Backend

    Stack

    React · TypeScript · Python · SQLite · SVG · CodeMirror · Vite · Chrome DevTools Protocol

    • Fan and professional modes share one session; analysis occupies reserved space beside or beneath the stage.
    • Tyres and pit calls, football formations and substitutions, and between-round boxing advice affect the models.
    • Cross-sport read-only queries return real recorded samples; unsafe SQL is rejected at the database boundary.
    View project
  7. Recorded from the running app in real time. Before filming, the seeded world was run ahead at top speed so a village has grown.

    Experimental

    Living Society

    Agents live in a seeded world, gather resources and interact, and any run can be replayed exactly. Multi-seed runs, scenario matrices and ablations test the design's own assumptions. One ablation found that switching the communication system off gave about 7.4% more population after 4,000 ticks. The project records that as a finding instead of tuning it away.

    Skills shown

    How it runs

    1. Pick a seed and a scenario
    2. Agents gather, trade and interact through bounded decisions
    3. Watch the world and click any agent to inspect it
    4. Replay any run exactly from its seed
    5. Compare runs across seeds, scenarios and ablations

    Layers

    1. Operations
    2. Interface
    3. Intelligence

    Stack

    JavaScript · Canvas · Seeded RNG · Node test runner · Playwright · Tabular Q-learning

    • Exact replay from a seed, so any interesting run can be reproduced.
    • 276 tests across 14 suites at the documented checkpoint, plus visual-regression and performance proofs.
    • A long-horizon run of 10 seeds of 4,000 ticks each succeeded on every seed.
    View project
  8. The running simulation rendered frame by frame at its own speed, two simulated minutes a second, early on a Monday morning; the camera moves, nobody is steered.

    Experimental

    Alder Court

    Around seventy residents of every kind of household live in an eight-storey block. Nobody is scripted: each person chooses what to do next from their needs, obligations, habits, relationships and household money, and says why. The aim is fidelity to everyday life, not a game. A Society now panel counts homes in deficit, the income gap, overcrowding, stress, isolation and lost sleep, and a lens rings every resident by the chosen measure.

    Skills shown

    How it runs

    1. Pick a seed: households, jobs and budgets come from it
    2. Each resident scores their next action from needs, habits and money
    3. They walk planned routes, predicting everyone around them
    4. Workers and pupils leave in the morning and return in the evening
    5. Society now tracks deficits, crowding, stress, isolation and sleep
    6. Ring every resident by a measure, or follow anyone to read their reasons

    Layers

    1. Operations
    2. Interface
    3. Intelligence

    Stack

    JavaScript (ES modules) · three.js · WebGL · Seeded simulation · Utility-based decisions · Reciprocal collision avoidance (ORCA) · Node test harness · Playwright

    • Decisions are scored from needs, obligations, habits, relationships and household money, and every choice carries its reason.
    • Society now shows the building’s pressures live; the lens paints them onto every resident.
    • Walkers predict each other and never walk into one another; doorways stay clear and lifts and stairs keep order.
    View project
  9. Recorded from the running app on a throwaway profile with the live forecast for its default city; the scene lab loading and scene-change waits are shortened.

    Partial

    WeatherComfort

    The home screen is a real-time 3D street where Gus, a stylised London commuter, walks on and reacts to how you will feel in today's outfit: sweating, freezing into an ice statue, losing an umbrella to the wind. Behind him are the full forecast, a ten-second comfort log, and a personal model that learns whether you run hot or cold and turns that into practical advice on what to wear.

    Skills shown

    How it runs

    1. Open the app: Gus walks on into today's forecast for your place
    2. Read today's outfit card and the hour-by-hour feel for your commute
    3. Log how you actually feel, with what you are wearing and where you are
    4. The personal model updates and explains what it has learned
    5. Preview any weather, time of day and reaction in the scene lab

    Rendering performance on a visible display and on phones is not yet measured.

    Layers

    1. Interface
    2. Intelligence
    3. Data
    4. Backend

    Stack

    React · TypeScript · React Three Fiber · Three.js · Node.js (native TypeScript) · node:sqlite · Open-Meteo · Vitest

    • The forecast is turned into how it will feel to you, hour by hour, for the parts of your day you actually spend outside or on transport.
    • The learner was tested by planting a known bias in fixture logs and checking it is recovered, with a negative control.
    • The outfit search is checked by brute force against the objective it optimises.
    View project
  10. Recorded from the running app's built-in demo of three fictional, intermarried families, with no live backend. Portraits are AI-generated stills; the "video" is a still with captions.

    Partial

    LegacyTree

    LegacyTree is a genealogy app for building a family tree with relatives. Each person carries photos, dates, places, a biography and tags. The tree can be explored and opened into profiles, and the same family can be read as a timeline of births, marriages and deaths. Behind it sit accounts, shared editing, privacy settings and a Supabase backend. The app was generated with Lovable, an AI app builder; the estate's own addition is a GEDCOM parser.

    Skills shown

    How it runs

    1. Explore a family tree as it grows in
    2. Open anyone's profile and play their introduction
    3. Match two separately built trees on the people they share
    4. Link them and see how any two relatives are related

    Layers

    1. Interface
    2. Data
    3. Backend

    Stack

    React · TypeScript · Vite · Tailwind CSS · shadcn/ui · Supabase · Framer Motion · GEDCOM

    • Interactive family trees whose members open into profiles with a video introduction, biography, favourite music and family links.
    • Two trees researched separately can be matched on the people they share and linked, with the kinship path between any two relatives explained.
    • Concurrent edits use optimistic locking, and likely duplicate people are flagged before a merge.
    View project
  11. Recorded from the running app (last committed version): gallery and coverage gaps, a design recipe with its exclusions, side-by-side comparison.

    Partial

    Design Observatory

    Design work is stored as versioned experiments, and the app only projects that store. Each version climbs a ladder from candidate to exemplar, so weak work cannot quietly set the bar. Every exemplar carries a design recipe covering type, colour, composition, motion, performance and accessibility, plus what it deliberately excludes. The gallery reports which design problems it still cannot answer, and any two designs can be compared side by side.

    Skills shown

    How it runs

    1. Study reference designs and store each attempt as a versioned experiment
    2. Critique rules flag what makes an interface look generated
    3. Strong versions climb to exemplar, each with a recipe of what it excludes
    4. Generate a web or app foundation from the estate templates
    5. Review the generated foundation against the same design rules
    6. What fails feeds back into the rules and the templates

    Layers

    1. Interface
    2. Data

    Stack

    Node.js · JSON data contracts · HTML / CSS / JavaScript · React + Vite foundation generator · Expo / React Native foundation generator · Playwright · node:test

    • A promotion ladder (candidate, qualified, exemplar, featured, archived, superseded) decides what the gallery shows.
    • Each design recipe lists what it excludes, so a transfer that brings back an excluded pattern fails.
    • Its Foundations view generates the estate’s web and app templates in a scratch folder and reviews them against the same design rules.
    View project
  12. Recorded from the running app: the salt mission, built only from its explicit teaching rules.

    Partial

    MoleculeSim

    You can browse and search every element, inspect representative atoms, then place atoms on the Bonding Bench. Only combinations covered by explicit teaching rules and recorded structures will form, such as water, salt and ethanol. Anything else stays visibly unsupported. Real-Chrome tests drive the missions, reduced motion and narrow-screen reflow, and a harness measures frame budgets.

    Skills shown

    How it runs

    1. Open the Bonding Bench with a guided mission ready
    2. Pick elements from the inventory
    3. Place atoms in the chamber
    4. Supported combinations form; anything else is labelled unsupported
    5. Inspect bonds in the structure explorer
    6. Look closer in the element atlas or build an atom

    Layers

    1. Operations
    2. Interface
    3. Intelligence

    Stack

    JavaScript (ES modules) · Canvas · JSON datasets · Node test runner · Chrome automation

    • Bounded rules: unsupported combinations are refused rather than invented.
    • Formation animations follow recorded structures and are labelled as a teaching model.
    • 37 unit tests and 14 real-Chrome checks, including reduced motion and narrow-screen reflow.
    View project
  13. Recorded from the running web version and its OCR server: find, photograph, read, match, collect. The location is simulated at the plaque, the plaque photo is generated, and the OCR wait is shortened.

    Partial

    Blue Plaque Hunter

    The map holds 2,264 plaques merged from public heritage sources, plus guided walks and daily quests. You pick a plaque, stand in front of it and take a photo. OCR reads the inscription, and collection only unlocks when the text matches that plaque and you are close enough to it. The server validates the claim and awards points. New plaques can be submitted, and they wait for moderation.

    Skills shown

    How it runs

    1. Open the map of plaques, walks and daily quests
    2. Pick a plaque and walk to it
    3. Stand in front of it and take a photo
    4. OCR reads the inscription and your distance is checked
    5. The server validates the claim and awards points
    6. Your collection and quests update

    Layers

    1. Interface
    2. Data
    3. Backend

    Stack

    Expo / React Native · TypeScript · Leaflet · React Native Maps · Express · Tesseract.js · Sharp · OpenStreetMap Overpass · ArcGIS REST

    • Imports and de-duplicates plaques from several public sources into one database, keeping each record's provenance and licence.
    • Collection is gated twice: the OCR text must match the plaque, and the device must be close enough to it.
    • The OCR server preprocesses photos and runs Tesseract behind tokens, rate limits and upload limits.
    View project
  14. Recorded from the running app: choose, upload, preview on the card, host, QR, phone. The AR view itself needs a phone camera and is not filmed.

    Partial

    QR3D Host

    The front page is one guided journey. Choose a 3D object or a picture, upload it, check how it will stand on the printed card, and host it. The server stores the file, creates a stable QR identity and a printable card that carries the tracking marker. Scanning opens the secure AR page, which loads the same hosted file, and the code can be re-pointed later without reprinting.

    Skills shown

    How it runs

    1. Choose a 3D object or a picture
    2. Upload it to your own server
    3. Check how it will stand on the printed card
    4. Host it: a stable QR identity is created
    5. Print the card with its QR code and tracking marker
    6. Scan on a phone and see it standing on the card

    Proved in desktop Chrome with a synthetic camera; anchoring on a physical phone is still a manual check.

    Layers

    1. Operations
    2. Interface
    3. Backend

    Stack

    Node.js · Express · Three.js · GLB / glTF · AR.js · WebSocket · TLS · Expo

    • Uploads are validated before anything is written: a GLB’s header and declared length must match the file.
    • A printed code keeps its identity; what it opens can be changed later without reprinting.
    • The printable card carries both the QR code and the square marker the camera anchors to.
    View project
  15. Recorded from the running app: search, scrub the timeline to February, list what is active.

    Proven

    Cultural Atlas

    You ask what is happening in a place, or on your dates. The server answers map, timeline, country-by-month and preference-match queries over a catalogue of 1,747 dated occurrences, and a React and MapLibre interface draws the results. Each record carries its evidence state (confirmed, calculated, expected or pending), and the interface shows that state instead of hiding it.

    Skills shown

    How it runs

    1. Ask what is happening in a place, or on your dates
    2. The server answers map, timeline and calendar queries over the catalogue
    3. The map, activity view and density timeline draw the answer
    4. Every record shows how certain its date and source are
    5. Share the exact view as a link

    Layers

    1. Operations
    2. Interface
    3. Data

    Stack

    React · TypeScript · Vite · Node.js · MapLibre GL · Canvas · Open-Meteo · World Bank data

    • A citation is not treated as a fetched source: of 1,240 cited sources the system has retrieved 7, and the interface says so.
    • Splitting fixed places from dated events cut each timeline-scrub update from about 816 kB to about 2 kB, and from 30 requests to one.
    • Found a map that rendered nothing because the bundler had broken MapLibre's worker URL without raising an error. The URL is now wired explicitly and a test guards it.
    View project
  16. Recorded from the running studio on a desktop GPU: two of its starting compositions, then presentation mode.

    Experimental

    FluidSim

    An image archive is reduced to a latent space by principal component analysis. A slow walk through that space is decoded every frame on the GPU, and the decoded dream becomes both the pigment and the force field of a WebGPU fluid. The result is glossy, folding relief paint threaded with luminous fibres. Each work is a small file covering the dream, flow, matter, camera, light and look. Live wind data for a chosen city can steer the whole field.

    Skills shown

    How it runs

    1. Pick a work or drop in an image archive
    2. The browser learns the archive's latent space
    3. A seeded walk drifts through that space
    4. Each decoded frame pours paint and force into the GPU fluid
    5. Present full screen, record, or export a still
    6. Render a master offline at the film tier

    Layers

    1. Operations
    2. Interface
    3. Intelligence

    Stack

    TypeScript · Vite · WebGPU · WGSL · Canvas · Vitest · Playwright · FFmpeg

    • The dream is a principal-component walk through a learned image archive, decoded on the GPU every frame.
    • The decoded image is both paint and force: it pours pigment and steers the fluid that carries it.
    • Drop in your own images or folder and the browser learns a new archive from them.
    View project

What I work with

Each area links to the projects on this page that show it. Lines marked “At work” come from my day job as a data engineer in insurance; that work is confidential, so it is listed rather than shown.

How these were built

I designed these systems, decided what counted as proof and verified the results. Most of the code was written by AI coding agents (Claude and Codex) working under my direction.

Every demo above is recorded from the project's own running app, on demo or scratch data. Where a project is hardware, or its live interface shows other private work, its caption says what the loop is instead.

Proven
The behaviour described was exercised end to end, with recorded evidence.
Partial
The core works; named parts are not yet proven.
Experimental
A lab or research system; read it as an experiment.