Firewatch TechnologyFIREWATCH//RANGERDATA ABSTRACTION LAYER — R&D STATUS
Firewatch R&D · Project Status

Ranger — the data abstraction layer, sized for the rest of us.

A business runs better when its objects — customers, orders, shipments, tickets — live in one governed, queryable, editable model, instead of being scattered across spreadsheets and app databases. Ranger is that data abstraction layer (DAL) for SMBs: define your business objects once, then query and edit them through the public OSDK wire contract, the industry's typed client standard — event-sourced writes, database-enforced isolation, deny-by-default security. This page tracks the build, phase by phase.

RANGER IS A WORKING NAME · UNDER ACTIVE DEVELOPMENT · UPDATED 2026-07-16

PHASES 0–4 SHIPPED
Foundations → security
584 TESTS GREEN
Unit · integration · conformance
OSDK-COMPATIBLE
Official client, unmodified
LIVE ON AWS
First stamp provisioned & demo-verified 07/14
READS YOUR DATABASE
Mapped-backing gate passed 07/15 — the client can't tell

Build timeline — where we are

Seven phases, each with a hard exit gate — we don't start the next until the gate passes. Every animation follows one continuing story: Acme Distribution, a Denver drinks distributor, and its orders. Read the scenario line first, then let the steps play — or drive them yourself with the step buttons. Hover any block for a plain description; click it for the full technical deep-dive.

The scenario
STEP 1/8
HOVER = DESCRIPTION · CLICK = DEEP DIVE · SWIPE ON MOBILE
CLICK FOR DEEP DIVE

Ranger in action — a hospital, cloned

The build timeline above shows how Ranger is made. This shows what it's for. Mercy Ridge Regional Hospital is a fictional hospital with a painfully real setup: five systems that don't talk — an EHR, a credentialing spreadsheet, an admissions feed, a lab system, a pharmacy. Watch them connect into one data abstraction layer, then watch the jobs a plain database can't do safely. All data below is fictional, created for this example.

The scenarioFive exports, four different ID schemes, allergies packed into pipe-delimited strings, social-security numbers sitting in plaintext. One afternoon later: a typed, linked, governed model — with the official OSDK as the read/write interface. Every record shown is invented for this demo.
SCENE 1/9
HOVER = DESCRIPTION · ALL DATA FICTIONAL

The three bets Ranger is built on

◆Wire contract is law

We implement the public OSDK API contract (/api/v2/ontologies/*), verified by a conformance suite that runs identical scenarios against the SDK project's own test double (@osdk/faux) and against us. The payoff: the official OSDK — typed clients, codegen, the whole developer experience — works against Ranger unmodified.

◆The edit log is the truth

Every write is an append-only edit; the queryable objects table is just a projection. CI proves it every run: wipe the projection, replay the log, get back an identical database. Full audit history and rebuildable indexes come for free.

◆Isolation the app can't forget

Tenant isolation is enforced by Postgres row-level security — forced, keyed on the request's tenant, running as a non-superuser role. Application code cannot cross tenants, even if buggy. Production deployments go further: one gapped stack per customer.

Newest result — reads from the database you already run

◆Mapped backing, proven on the wire

A model can now declare a type as backed by a table in the Postgres you already operate — no migration, no copy. The platform routes reads for that type (get, list, search, link traversal, object sets) to a data-plane engine that reads your table live. The exit gate, passed 07/15: the official OSDK client reads a native type and a mapped type through the same wire API, with correct results, and cannot tell which store answered.

◆Reads today — writes by design, not delay

Write-back on mapped tables is deliberately sequenced behind a change-capture design so the edit-log guarantee (every change auditable and replayable) holds for your tables too — including changes made outside the platform: a raw SQL update against your database will surface as a governed edit event and webhook with no API call involved. That design is in cross-review now. Until it lands, mapped types are read-only, and row-level policies on them are refused at publish rather than silently unenforced.

◆Beyond Postgres — measured, and it passed

Reaching MySQL, SQL Server, and Oracle sources is ruled: mount them as foreign tables inside a Postgres we run, so one query engine serves every source. The lab spike has passed its gate: a 57-test rig ran the full read-correctness suite green against a foreign-mounted MySQL with zero engine changes, with the pushdown operator matrix and latency numbers measured at 0 ms and 20 ms injected round-trip — findings recorded and their fixes adopted. Managed Postgres (RDS/Aurora) rides the same mount path. Next: the offer sheet gains per-source coverage rows — measured, not promised.